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AUDIO FILE DISTRIBUTION AND PRODUCTION SYSTEM 
SPECIFICATION 



Be it known that I, Tim chase, a citizen of the 
United States of America and a resident of the City of 
Holmdel in the State of New Jersey have invented certain 
S new and useful improvements in a 

AUDIO FILE DISTRIBUTION AND PRODUCTION SYSTEM 
of which the following is a specification. 

REFERENCE MATERIALS AND SOFTWARE 
INCORPORATED BY REFERENPF! 

10 .The present application claims priority, from 

prpvisipnal patent application Serial No. 60/003,164, 
filed September 1, 1995, the entire content of which is 
expressly incorporated herein by reference including all 
software appendices and attached papers filed with the 
15 '164 provisional application. . 

The software utilized to implement the preferred 
embodiment of the present invention is attached in 
Appendices A-E on 5-3 V diskettes labeled in the 
following manner. The software utilized to implement 
the affiliate controller of the preferred embodiment of 
the present invention is attached as Software Appendix 
A entitled "DAX Source." The software utilized by the 
affiliate controller to interface with the digital audio 
£a£ds ±s -filed herewith in Software Appendix B entitled 
•"Driver Source" and Software Appendix c entitled "DAC 
. . ! DSP Source." . The functions of the digital audio-' card- 
are described in the papers attached to the '164 
provisional application entitled " DAC Driver Design," 
"DAX Audio Server Design," "Design Notes," . and 
30 "Requirements." The software that provides cooperation 

between the remote control terminal and the affiliate 
controller is filed herewith in Software Appendix D , 
entitled "Jock Box Terminal Source Code." The software-, 
utilized by the distribution management system to 
control the delivery subsystem are filed herewith in 
Software Appendix E entitled "DMS Source." 
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The multiplexer utilized within' the delivery 
subsystem in connection with the preferred embodiment 
may be . that disclosed in applicant's co-pending 
application entitled "Method and Apparatus for Dynamic 
Allocation of Transmission Band Width Resources," filed 
August 16, 1995 as a provisional application, Serial No. 

/ (Attorney Docket 10872US01) and on August" 16, 

1996 as a non-provisional application, Serial No. 

/ (Attorney Docket 10872US02) . 

All of the software appendices A ■ through E 
referenced above, along with the. above-referenced 
papers., provisional and non-provisional applications are 
expressly incorporated herein by reference in their 
entireties. 



FIELD OF THE INVEHTCTftH 

The present invention relates generally to the 
distribution of live and recorded audio and, in 
particular, to an integrated distribution and playback 
system that provides distribution of digitized live 
audio, single audio files, and/or groups of audio files 
and playback instructions from a head end transmitter to 
one or more end user receivers. 
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BACKGRO mm OF THE INVEWTTnw 
Nationally syndicated radio programs and national 
advertizing campaigns make up a large part of the radio 
broadcasting industry. Current methods of distribution 
of these programs . and advertisements to local 
broadcasting stations and subsequent production is 
surprisingly cumbersome and inefficient. 

In. one common scenario, a national broadcaster will 
offer a radio program to a local radio station. The 
station gets the program, and in return the national 

.broadcaster is provided additional air' time on the 
■ station to use for national advertizing spot's . The 
national broadcaster then records an entire show that 
includes the radio program and national advertisements 
onto a compact disc, digital audio tape or the like A 
compact disc, or tape of the recorded show is then 
Physically delivered to various local stations. ~ 
usually by an overnight delivery service. 

The recorded show is divided into segments, and 
between each segment is a gap which allows the local 
station to broadcast local spots such as- local ads, 
station identification, or local news. Because the 
station operator needs to know when these gaps are going 
to occur and how long they will last, the national 
br6adcaster must also provide a printed show format. 
The show format provides the station operator with 
information such as total show running length, out cues, 

-and length of - segment~~gaps." - - ■ - — ------ 

To broadcast the show, the station operator plays 
the compact disc containing the prerecorded show while 
listening for- out cues. When he hears an out cue he 
presses play on a playback device containing a recording 
of the local spot or. gives the local newsperson the 
signal to begin speaking. The local spots are timed to 
end when the segment gap is over. 

A number of problems are created for the national 
distributor using such a method, of show distribution: 



The manufacture and recording^ a compact disc for each 
local station is expensive and because the discs are 
usually only used once and then destroyed, this process 
is wasteful. Preparation of the" compact discs ' and ■ 
subsequent delivery can take up to a week. This tine 
-delay prevents distribution of shows that are up to 
date. Because the recordings must be physically sent to 
every , local station, the cost of shipping is- high. if 
national advertisers want to target only certain regions 
of the country with certain ads, different recordings 
must be made and shipped to stations in those regions. 

At the local radio station , problems are created by 
the inflexible nature of a prerecorded show and the real 
time splicing of local spots into the broadcast based 
15 upon printed show formats and audible cues. These 
problems can cause wasteful dead air time and audibly 
unpleasant, abrupt changes between national and local 
segments . 
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SUMMARY OF THE INVENTION 
According to. a first embodiment of the invention there is provided an improved 
method of transmitting at least audio information from production systems to one or more 
among a predetermined group of tail end users distal from the production systems, the 
5 improved method comprising the steps of: 

a. receiving at least a first audio signal on a first production system and at 
least a second audio signal on a second production system; 

b. digitally encoding the first and second audio signals with a lossy 
compression algorithm to yield respective first and second lossy encoded files of lossy 

10 audio information; 

c. predetermining a first group of tail end user apparatus for use of the first 
lossy encoded file, and a second group of tail end user apparatus for use of the second 
lossy encoded file; 

d. transmitting the lossy encoded files from the first and second production 
. is systems to a hub for automatic selective forwarding of the first and second lossy encoded 

files by the hub to the first and second groups of tail end user apparatus respectively; and 

e. receiving, decoding, and playback broadcasting of the first and second 
lossy encoded files respectively on the first and second groups of tail end user apparatus, 
said decoding using a decoding algorithm for decoding of the lossy encoded file encoded 

20 with the lossy encoding algorithm. 

According to a second embodiment of the invention there is provided an 
improved method of transmitting at least audio information from a production system to 
one or more among a predetermined group of tail end users distal from the production 
system, the improved method comprising the steps of: 
-25 - - -a. — -receiving a first audio signal on the production system; - ; 

b. digitally encoding the audio signal with a lossy compression algorithm 
to yield a lossy encoded file of lossy audio information; . . 

c. selecting which selected tail end user apparatus among the group of tail 
end user apparatus should receive and use the lossy encoded file; 

30 d. for each of the selected tail end user apparatus, determining whether to 

transmit the lossy compressed digitized file through a satellite link or other link; 

e. for each of the selected tail end user apparatus, automatically 
transmitting the lossy encoded file to the respective selected tail end user apparatus 
through the respectively determined link; 
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f. receiving and storing the lossy encoded file on the selected tail end user 

apparatus for subsequent decoding and use of the lossy encoded file by the selected tail 
end user apparatus, said decoding using a decoding algorithm for decoding of the lossy 
encoded file encoded with the lossy encoding algorithm. 

According to a third embodiment of the invention there is provided an improved 
method of transmitting at least audio and data information from a production system to 
one or more among a predetermined group of tail end users distal from the production 
system, the improved method comprising the steps of: 

a. receiving a first audio signal on the production system; 

b. digitally encoding the first audio signal with a lossy compression 
algorithm to yield a first lossy encoded file of lossy audio information; ' 

. c. producing a separate data file of non-audio information, including a 

playlist; 

d. predetermining which selected tail end user apparatus among the group 
of tail end user apparatus should receive and use the first lossy encoded file and the data 
file; 

e. automatically transmitting the first lossy encoded file and the data file 
from the production system to the predetermined tail end user apparatus through an 
extraterrestrial satellite; 

f. automatically receiving and storing the first lossy encoded file and the 
data file on the predetermined tail end user apparatus, without further lossy compression 
of the lossy audio information in the first lossy encoded file, for subsequent decoding and 
use of the lossy encoded file, either oh demand or according to the play list, sard decoding 
using a decoding algorithm for decoding of the first lossy encoded file encoded with the 
lossy-encoding algorithm. - - 

According to a further embodiment of the invention there is provided an 
improved method of transmitting at least audio information from a production system to 
one or more among a predetermined group of tail end users distal from the production 
system, the improved method comprising the steps of: 

a. receiving a first audio signal on the production system; 

b. digitally encoding the audio signal with a lossy compression algorithm 
to yield a first lossy encoded file of lossy audio information; 

c. producing a separate data file of non-audio information including a 
playlist associated with the first lossy encoded file; 
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d. selecting which selected tail end user apparatus among the group of tail 
end user apparatus should receive and use the first lossy encoded file and the data file; 

e. automatically determining whether to transmit the first lossy 
compressed digitized file and the associated data file to the selected tail end user 
apparatus through a satellite link or other link; 

f. transmitting the first lossy encoded file and the associated data file to 
the selected tail end user apparatus through the determined link; 

g. automatically receiving and storing the first lossy encoded file and the 
associated data file on the selected tail end user apparatus, for subsequent use of the data 
file and decoding and use of the lossy encoded file, said decoding using a decoding 
algorithm for decoding of the first lossy encoded file encoded with the lossy encoding 
algorithm. .. 

According to a further embodiment of the invention there is provided an 
improved method of transmitting at least audio information from a production system to 
one or more among a predetermined group of tail end users distal from the production 
system, the improved method comprising the steps of: 

a. , receiving first and second audio signals on the production system; 

b. digitally encoding the first arid second audio signals with a compression 
algorithm to yield respective first and second encoded files of audio information; 

c. predetermining one or more tail end users from among a group of tail 
end users and generating digitally encoded instructions to the tail end user apparatus for 
decoding and playback of the first and second encoded files; 

d. automatically multiplexing the first and second encoded files and 
encoded playlist into a multiplexed data stream; 

e. - automatically - transmitting- - the multiplexed data stream- to the - 
predetermined tail end user apparatus through an extraterrestrial satellite; 

f receiving the multiplexed and transmitted data stream, de-multiplexing 
the data stream, providing output including the encoded file and the encoded playlist on ' 
the tail end user apparatus, and decoding and using the encoded file according to the 
encoded instructions. 

According to a further embodiment of the invention there is provided an 
improved method of transmitting at' least audio information from a head end to one or 
more among a predetermined group of tail end users distal from the head -end, the 
improved method comprising the steps of: 

- a. receiving a first audio signal on a production system; 
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b. digitally encoding the audio signal with a lossy compression algorithm 
to yield a lossy encoded file of lossy audio information; 

c. predetermining one or more tail end users from among a group of tail 
end users; 

d. transmitting the lossy encoded file from . the head end to the . 
predetermined tail end user apparatus; 

e. receiving the lossy encoded file and decoding of the lossy encoded file 
on the predetermined tail end user apparatus, said decoding using a decoding algorithm 
for decoding of the lossy encoded file encoded with the lossy encoding algorithm; and 

f. local storage and automatic insertion of a spot segment into a playback 
generated by the predetermined tail end user apparatus. 

The preferred embodiment of the present invention includes an audio delivery 
system having, at a head end, a production subsystem which communicates with a 
delivery subsystem via a local area network, ISDN connection, and the like. The delivery 
subsystem communicates with an affiliate subsystem, at a tail end, via a satellite link, 
ISDN link and the like. The delivery subsystem communicates with an affiliate 
subsystem, at a tail end, via a satellite link, ISDN link and the like. The production 
subsystem enables a producer to create audio events which represent sequences of audio 
which are played to completion before another audio event occurs. Audio events are 
stored as audio files. Each audio event may include one or more of an audio sequence, 
text information, delivery instructions, and an attribute list having contact closure 
information and the like. Optionally, multiple audio events may be assembled at the 
production subsystem to form a play list. The audio files are transferred to the delivery 
subsystem. The delivery subsystem places the audio files in delivery envelopes and 
transmits the envelopes to the affiliate terminals. In addition, the delivery subsystem-may 
transmit live audio and related contact closure information to the affiliate terminals. The 
affiliate terminal may be located at a user site. The affiliate terminals may store these 
events on the hard drive, play the events in real time or pass events to other affiliate 
terminals. The affiliate terminal may later play stored audio events. 

The audio delivery system of the preferred embodiment supports at least seven 
basic services. The audio delivery system enables audio files to be introduced into the 
system, along with auxiliary information about each file such as traffic information, 
formatics, incues, and the like. In addition, the audio delivery system enables bundling of 
audio events and supporting documentation into an aggregate delivery package, such as a 
play list. The bundled audio events and documentation are transmitted to desired affiliate 
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tcrminals as a single package or envelope. Each package may be separately addressed to 
a particular affiliate terminal, and/or groups of affiliate terminals. This addressing 
information is referred to as delivery"mstructions. The audio delivery system further 
supports an integrity check to insure that packages are distributed properly. 
5 To overcome the problems and limitations of the prior art, the disclosed 

invention has various embodiments which provide: 

an integrated system for the distribution and subsequent playback of high quality 
live audio, single audio files, and groups of audio files; 

selective distribution of live audio, single audio files, and groups of audio files to 
10 selected end users, or groups of end users based upon, for example, geographic region; 

data compression on audio signals to allow cost efficient transmission of live 
audio, audio files and groups of audio files without significant loss of audio quality, 

an integrated audio distribution- and playback system that allows a user at a 
distribution center to control the order in which groups of audio files will be played by a . 
is distant playback machine; 

an integrated audio distribution and playback system that allows a user at the 
head end to produce a complete show for broadcast by local radio stations; 

an integrated audio distribution and playback system that allows local audio 
segments to be integrated into a show that is produced by a national distributer of audio 
20 segments; 

a playback system that produces audibly pleasing and smooth transitions from 
one audio file or segment to another audio file or segment; 

system' components that are economical to manufacture and compatible with 
existing devices; and 
25 a user friendly- system- with easy and flexible programmability. 

BRIEF DESCRIPTION OF THE DRAWINGS 
Fig, 1 generally illustrates a block diagram of an audio delivery system. 
Fig. 2 generally illustrates a block diagram of a production subsystem. 
30 Fig. 3 generally illustrates a block diagram of a delivery subsystem. 

Fig. 4 generally illustrates an affiliate terminal. 

Fig. 5 illustrates a perspective view of a remote affiliate remote control terminal. 
Fig. 6 illustrates a block diagram of a digital audio card. 

Fig. 7 illustrates a block diagram of a functional representation of a processor 
35 utilized in connection with the digital audio card. 
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Fig. 8 illustrates a functional block diagram of the affiliate controller when 
operating in connection with a digital audio card. 

Fig. 9 illustrates a block diagram of an audio file, cart file and play list file 

format. 

5 Figs. 1 OA and 1 OB illustrate a flow chart of the processing sequence followed by 

the digital audio card and an affiliate terminal to effect a playback operation. 

Fig. 11 illustrates an exemplary cross fade operation between two stored 
segments followed by play of a local segment not stored on the affiliate terminal. 

Fig. 12 illustrates an alternative embodiment of the file delivery system. 
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BSTAILED DBBflHTPTICM OF TKT. PREPFRBPn EMBODTMl^ 
DEPIKITIONS 

Initially, a list of definitions is provided for 
commonly used terms. 

One or more audio segments grouped 
on a playlist and delivered to at 
least one affiliate terminal. By 
way of example, an audio program may 
represent the Howard Stern show 
Casey Cassims Top 40, and the like! 

An audio event containing a 
continuous sequence of audio signals 
having defined beginning and ending 
points. The audio event is- played 
by the affiliate terminal from 
beginning to completion before 
another event (audio or command) may 
occur. By way of example, an audio 
event may represent a sound bite, a 
song, a portion of a song, a portion 
of a syndicated show between 
commercials , a commercial and the 
like. 



Audio Program 



Audio Segment - 



Audition Audio 
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Cirt Machine 



Cart Pile 



A short audio sequence 
representative of the content of an 
audio program. For / instance, an 
audition audio signal may represent 
the first fev seconds of a song and 
may be played to the affiliate 
terminal user to acquaint the user 
with the associated audio segment or 
audio program. 

An audio playback device at an 
affiliate terminal used to play 
local audio segments, such as from 
tape.- - Cart -machines ar"e"b"f ten used" 
to record and play back commercials 
and news spots. 

A file uniquely associated with an 
audio file. The cart file includes 
the audio file name, the starting 
and ending- offsets into the audio 
file, marker attributes, incues, 
outcues death date and first use 
date. 



Contact Closure 
Commands 



Instructions directing affiliate 
terminals to open or close contacts, 
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Data packet 
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Death Date 



Delivery 
Instructions 



Formatics 
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Out of Band 
Control 



Playback List 



Audio Piles 



such as to turn on and off cart 
machines. 

A segment of data passed through the 
multiplexer as a discrete unit, to 
which header information is attached 
prior # to modulation and 
transmission. By way of example, 
audio segments and audio programs 
may be subdivided into data packets 
by the multiplexer and transmitted 
in a time division multiplexed 
. manner to the affiliate terminal. 

A preassigned date upon which an 
affiliate terminal automatically 
deletes 1 an audio segment^ and/or 
audio program from the memory of the " 
affiliate terminal. 



Instructions provided to inform the 
delivery subsystem of which 
affiliate terminals should receive 
each data file during distribution. 

The format or layout of an audio 
program which may be representative 
of a radio show. For example, the 
format may identify locations within 
an audio program at. which a local 
affiliate station may insert local 
commercial spots. In addition, the 
format or layout would include 
incues and outcues for transitional 
segments and the play times for 
audio segments . 

Control commands which' may be 
di_rected_to_an_af filiate ^terminal as 
p'art of "the multiplexer's internal 
communications, such as information 
identifying the channels over which 
a single message is being 
transmitted. . 

An outline or log, associated with 
a particular audio program, 
containing information uniquely 
identifying each audio 
segment/clip/event within the 
associated audio program. 



Recorded audio with 
structure . Audio 



no internal 
files may 
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Live audio 



Delay Play Audio 



represent individual commercials or short or 
. long form program segments. 

Shows which are broadcast as they are 
received without recording the show on the 
affiliate terminal". Live audio may contain 
synchronized commands embedded therein 
within the ancillary . data stream. The 
synchronized commands may be used to 
trigger affiliate functions, such as initiating 
commercial playback by a card machine at 
the affiliate terminal. 

- Shows which are recorded to disk but 
.played back almost immediately (e.g., within 
five to ten minutes). The shows are recorded 
as received but the disk space is freed when 
the show is played. 



SYSTEM OVERVIEW 

Fig. 1 illustrates a block diagram of an audio delivery" system 10. The audio 
delivery system 10 includes at least one production subsystem 12, at least one delivery 
subsystem 14. and at least one affiliate terminal 16. As shown in Fig. 1, each production 
subsystem 12 may comrnunicate with one or more delivery subsystem 14 via any 
conventional" medium ~which~supports the transmission of digital" data: By way of 
example, the interconnection (illustrated at line 13) between a production subsystem 12 
and the delivery subsystem 14 may be a local area network, an ISDN link, a conventional 
telephone link, a satellite link and the like. As a further option, each delivery subsystem 
1 4 may communicate with more than one production subsystem 1 2. 

Each production subsystem 12 enables a user to produce data files, which 
generally refer to audio events/segments/clips, audio files, cart files, playback list files, 
text files, video files and delivery 
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instruction files (as defined in the DEFINITIONS 
section) . While the delivery and production subsystem 
are illustrated as functionally separate units in Fig. 
2, both subsystems may be implemented at a' comment site' 
(and a common system) , thereby avoiding the need for 
connection 13. 

.The delivery subsystem 14 receives audio files and 
sequences of audio files containing audio segments and 
audio programs, respectively, . from the delivery 
subsystem 14 along link 13. In addition, the delivery 
subsystem receives live audio signals along links. 15. 
The delivery subsystem 14 may also receive contact 
closure commands along links 15. The delivery subsystem 
14 combines signals received upon link 13 and links 15 
and outputs same via link 17 to the affiliate terminal 
16. The link 17 may represent a satellite link, an ISDN 
link, and the like. Optionally, the delivery subsystem 
14 may receive information from affiliate terminals via 
link 17 or link 19. 

Optionally, the delivery subsystem 14 may assemble' 
data files (e.g. , audio files, cart files, commands, 
play list files, text files, video files and the like) 
into a single "envelope". The "envelope" may include 
address information about the destination affiliate 
" ie'irminals . The delivery subsystem directs outgoing 
.envelopes of audio files ' to individual affiliate 
terminals based on the address information. Optionally, • 
the address information may designate a group of 
affiliate terminals as the destination for an envelope 
(e.g., midvestern radio stations for a syndicated show). 

The affiliate terminal 16 receives incoming 
envelopes from the delivery subsystem 14 and processes 
same in a desired manner. Optionally, the affiliate 
terminal 16 may inform the delivery subsystem 14 , via 
link 19, when the affiliate terminal 16 does not receive 
an expected audio file. The affiliate terminal 16 may 
store incoming audio files on a . hard disk and replay 
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these audio files later based on instructions < e .g. 
Playback list) received with the envelope or based on 
instructions from an operator at the affiliate terminal 
Alternatively, the affiliate terminal 16 may receive and' 
immediately replay incoming audio data as received, such 
as during broadcast of live programs (e.g., the news) 
As a. further alternative, the affiliate terminal 16 may 
interleave local programs (played from tape on local 
CART machines) and audio programs received from the 
delivery system 14 (stored on the hard drive) during a 
Playback operation. The" affiliate terminal 16 may 
-utilize an automated cross fading, operation when mixing 
an ending portion of one audio segment and a beginning 
portion of a next audio segment. 
15 The auxiliary terminal 16 outputs analog audio 

signals over link 19 to.be broadcast from the radio 
station. Lines 21 and 2 3 support outgoing contact 
closure commands, such as transmitted from the affiliate 
terminal 16 to a CART machine. Line 23 receives sensor 
20 input signals such as to inform the affiliate terminal 

16 of the present state of a CART machine and the like. 
The affiliate terminal 16 outputs audition audio signals 
over line 25 to a user at the affiliate terminal. 

JDAXA FORHAT 

25 Fi< 3- 9 generally illustrates an exemplary data 

format^ for use in connection with the preferred 
embodiment of the present invention. While it is 
understood that the present invention is not limited to 
audio data production and transmission, for purposes of 
30 illustration, it is assumed that an audio program is 

produced and transmitted. Fig. 11 illustrates a play 
list file 4 00 that defines a program of audio segments. 
The audio segments in the play list file may be 
displayed to the user in an outline format. The play 
list file 400 may include a play back list 402 of file 
names (e.g., 404, 420 and 436) identifying each audio 
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segment to be played. The file names 4 04, 420 and 43 6 
represent file names and directory, paths to cart files 
406, 422, and 438, respectively. Each cart file 406, 
422 and 436 uniquely . identifies an audio segment 414, 
432 and 434, respectively. Each cart' file 406, 422 and 
438 includes a path name 4 08, 4 24 and 4 40, respectively, 
to an audio file 415 and 4 30 containing a corresponding 
audio segment. Audio file 430 includes the audio 
segments 432 and- 434. for cart files 422 and 438 . 

Each cart file (406, 422 and 438) also includes 
beginning (410, 426 and 442) and ending data frame 
.numbers (412, 428 and 444) into the corresponding audio 
file. The beginning and ending data frame numbers 
identify the starting and ending points of. the 
corresponding audio segments. Each cart file may also 
include attributes for a corresponding audio segment,, 
.such as markers (used to initiate DAC events' as 
described below) , incues, outcues (to tell the user when 
a segment will end) , text description (comments 
describing an audio segment) , death date (the date upon 
which the affiliate automatically deletes the audio 
file), and first use dates (the date upon which the 
affiliate terminal will first be allowed to access the 
audio segment) . 

. During operation, text, outcues, comments and the 
like may be obtained from the audio files, cart files 
and play list - files and displayed . to the user. This 
display may include the display of a playback list by 
audio segment title, along with breaks for local spots 
and segment play times. 

PRODUCTION SUBSYSTEM 

Fig. 2 illustrates the production subsystem 12 in 
more detail . The production , subsystem 12 includes a 
production processor 24 which communicates with a 
delivery instruction input unit- 32, a traffic and 
formatics input unit 28, an audio input unit 2 6 and • a 



contact closure input unit 30. . The delivery subsystem 
includes a hard drive 3 5 for storing audio files 
associated with audio segments and audio programs prior 
to transmission to the delivery subsystem 14. The audio 
and contact closure inputs 26 and 30 supply audio and 
contact information signals to a CODEC 31, such as the 
CDQ prima coder/ decoder which is commercially available 
from Corporate Computer Systems, Inc. , located in 
Hblmdel, New Jersey. The CODEC 31 may encode the 
incoming audio signals based on a number of conventional 
"lossy-type" encoding algorithms such as the MUSICAM 
algorithm which is commercially available from Corporate 
Computer Systems, Inc. Optionally, a different encoding 
algorithm may be used in the CODEC 31. 

The CODEC 31 further receives contact closure 
instructions from the input 3 0 and incorporates these 
contact closure instructions into the output encoded 
audio signal. The output of the CODEC 31 is supplied to 
a digital audio card (DAC) 33, which is explained in 
more detail below in the section entitled DIGITAL AUDIO 
CARD. The DAC 33. relays the encoded audio data and- 
contact closure data to the processor of the delivery 
subsystem 12 for temporary storage while delivery 
instructions and traf fic/ format ics information are 
•produced and attached thereto. The DAC 33 may decode 
the output signal from the CODEC 31 and play the decoded 
audio signal to the _user ,to_ enable .the. user_ to„ hear .the_. 
resultant audio signal once encoded and decoded 
according to a current set of compression parameters. 

Optionally , the producer may initially listen to 
the decoded output of the DAC 3 3 without recording the 
encoded audio signal from the CODEC 31 , such as to 
determine whether the current parameter settings of the 
CODEC 31 need to be changed. Once the parameters of the 
CODEC 31. are set to the satisfaction of the producer, 
the producer may select a record option. Responsive 
thereto, the production processor 24 and the DAC 3 3 



cooperate to record the encoded audio output signal from 
the CODEC 31 on.the'hard drive of the delivery subsystem 
12. As a further option, while recording, the DAC 33 
may be switched to turn the playback operation off . 
5 As a further alternative, .the DAC 33 may be 

instructed to pass a new incoming encoded audio signals 
from the CODEC 31 to the processor 24 for storage on the 
hard drive, while simultaneously reading a previously 
encoded audio signal from the hard drive of the delivery 
10 subsystem 12. . The DAC 3 3 may decode and play the 

previously stored audio program to the producer while a 
new audio program is being encoded by the CODEC~*3i. and . 
stored on the hard drive, in this manner, the -delivery 
system of the preferred embodiment supports simultaneous 
15 recording and editing operations of first and second 

audio programs, respectively. 

Optionally,- the processor 24, may attach delivery 
instructions and traffic and formatics to audio segments 
and audio programs when stored in the data base 35. 
Once an audio segment or program is completed, the 
producer may instruct the processor 24 to transmit the 
audio segment or program over link 13 to the delivery 
subsystem. 

By way of example only, the production subsystem 12 . 
may: .be located in an advertising agency which will 
produce commercials for a national broadcaster. Using 
this approach, the _agenc y may perform the '-production 
function, and the resulting audio programs may be sent 
directly to the delivery subsystem 14 via ISDN links and 
the like without further involvement of the -national 
broadcaster. 

By way of example only, the audio input 2 6 may 
, represent a. digital audio tape player, a compact disk 
player and the like. The system may also support direct 
3 5 digital inputs such as AES/EBU: The traffic input may 

constitute a keyboard for entering a simple play 
instruction or a complex outline of an audio program 
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including inoues, outoues and the like . Tne contact 
closures may be used to start and stop CART machines and 
the l 1Jce as explained below. The delivery instruction 
input 32 enables the programmer to input all information 
reared- to deliver an audio - program to a desired 
affiliate terminal or group of terminals. The delivery 
instructions may include the name of the intended 
affiixate terminal , group of . affiliate terminals, the 
name of the sender, the relevant billing information, 
termination data and the like. 

By way of example, only, the production subsystem 
*ay include the PACE syste* which w as commercially 
available from New Jersey and is now . used by CBS. 

DELIVERY SUBSYSTEM 

. Fig. 3 generally illustrates the delivery subsystem 
in more detail. The delivery subsystem 14 includes a 
distribution management system 34 ( DMS ) which receives 
data files, such as audio files, cart files, play list 
files, command files, text files, video files and the 
like from the production subsystems 16.' The DMS 34 may 
receives communications from affiliate terminals along 
line 4 2, such as status reports, billing reports, 
delivery confirmation of data files and the like 
Optionally, the DMS 3 4 may receive delivery instructions 
from the production subsystem. The delivery subsystem 
14 collects incoming data files and may assemble these 
data files into "envelopes" containing commonly 
addressed data files, address information for 
destination affiliate and/ or" hub terminals, address 
information for destination groups of affiliate and/or 
terminals, priority delivery information regarding the 
latest delivery time of the envelope, a routing path 
list identifying each affiliate/hub terminal that has 
already received the envelope and the like. 

The DMS 34 passes the envelope to the multiplexer ■ 
22 along data line 34a. The multiplexor 22 may divide 
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the envelope into records for transmission along one or 
more channels. Optionally, the DMS may control 
operation of the multiplexer 22 via time slot control 
line 34b. The DMS 34 may also pass commands, • intended ' 
for affiliate and/or hub terminals, along an out of band 
control line 34c to the multiplexer 22. 

Alternatively, the multiplexor 22 may be controlled 
by a separate processor, in which case the DMS 3 4 would 
connect with the multiplexor 22 solely through a data 
output line 34a.. The out of band control line 34c and 
time slot assignment line 34b would be driven by the 
separate processor controlling the multiplexor 22. 

As a further alternative, the production subsystem 
12 may directly control addressing of the delivery 
subsystem 14, in which case the DMS 34 would pass data 
files to the multiplexor 22 without addressing 
information therewith and without grouping the data 
files into "envelopes". 

The delivery subsystem 14 may include at least one 
CODEC 18 for receiving live analog audio signals along 
lines .40. and encoding same based on one of several known 
encoding algorithms. The DMS 34 controls operation of 
the CODECS 18 via a control line 34d. The multiplexer 
22. receives digitally encoded audio signals from the 
GODECs 18. The multiplexer 22 operates in a manner set 
forth in the above referenced co-pending application 
Ci " COrpor _ a1: 5 d b _ y . r< L fe ?l en 5 e )_ to pass incoming. data .along 
one or more transmission channels to a modulator 44. 
The modulator 44 may transmit signals received from the 
multiplexer 22 to a satellite. 

In the foregoing manner, the delivery subsystem 14 
collects data files including audio files, cart files, 
Play list files, command files, text files, video files 
and distribution ■ information from the production 
subsystem.. The delivery subsystem 14 further receives 
live audio signals and ancillary data, such as contact 
closure information, via CODECS 18. .Data is transmitted 



t= af flllate and/or hub ternt . nals a aesirea 

*" e ; the Preferred embodiment, the delivery 
subsystem utilizes a satellite connection to transmit 
*ata to affiliate terainalS( ^ present JJ^* 

n=t so Ixmited. Alternatively, the delivery subsystem 
t aZi data al ° n5 ^ — i« 

sr d rrr : f di9itaiiy encoded data * * — -e.^ 

' dnc ,1 * ^ Parti = Ular • •PPlic.tion. For 
instance, the delivery subsystem K nay transaiit ^ 
dxgitany ncoded data along isdn e 

When low transmission rates are acceptable, the delivery 
subsystem 14 »ay utilize conventional telephoned Z 
transmit the digital data. 

AFFILIATE TERMINAL 

detail',! iUUStratSS an *«Uiate terminal 16 in more 
detail The affiliate. terminal 16 may be lo= a ted a t . 
receiving station or end user site. The affiliate 
terminal 16 includes an ante „ na S1 ^ receiv . 
incoming l ive data rackets, data files and envelopes via 
-satellite 2 o from the delivery . subsystem 
optionally, the antenna Si may transmit . return 
information, such as delivery information that an audio 
program has or has not been received, Incoming 
information is. demodulated in an RF demodulator 53 a nd 
Passed to a demultiplexer 50 . - The- demultiplexer 50 is 
configured to be compatible with the multiplexer 22 of 
the- delxvery subsystem - 14V ' The~d 6 »ultipTe X ^ so "may 
^multiplex incoming, data records from one or more 
channels to reassemble at least one envelope. The 
demultiplexer 50 may also demultiplex output out of band 
commands along line 66. Optionally, the demodulator 53 
aay be controlled to receive real time live audio data 
encoded, but not formatted into audio files (as 
described above) . The encoded a udio data is received as 
a continuous data stream of data packets of data frames. 
When, the demultiplexer 53 is configured to receive a 
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llVe audio data st "«>' the DAC S2 is set in a .. U ve 
mode- to receive the data stream. m this » anner the 
encoded data stream of live audio data is decoded and 
played back in real time. 

The affiliate terminal further includes an 
affiliate controller 46 which receives data files such 
as audio files, cart files. play list files> text ^ 
video files, and commands from the demultiplexer SO 
The affiliate controller 46 »ay represent a personal 
computer running a conventional operating system, such 
as Windows 95 offered by Microsoft. The affiliate 
controller 46 may store the incoming data on a memory 
48. The affiliate controller 46 includes at least one 
digital audio card (DAC) 52, explained below in more 
15 detail. 

The affiliate terminal 16 outputs an audio signal 
over at least one of an analog output line 56 for 
broadcast by the station or over a digital output line 
via an AES/EBU line. The affiliate terminal 16 may 
20 include an audition, audio output line 58 from DAC 52 

which enables an affiliate user to listen to at least a 
portion of audio segments or audio programs stored on 
the memory 48. A remote control terminal 54 may be 
.provided to afford the affiliate user remote control 
over at least a subset of the functions performed by the 
affiliate controller 46. By way of example, the remote 
control terminal 54 and audition audio headset 5? may„be 
located in £he ' DJ ' s booth " at a radio station to enable : 
the DJ to audition, listen to, and control play of audio 
segments and programs stored on the memory 48. The 
remote control terminal 54 enables the . DJ to select 
desired audio segments and programs stored on the memory 
48 from within the DJ's booth even though the affiliate 
controller. 4 6 is located remote from the DJ's booth. 

Lines 60 and 62 represent contact output control 
lines and, sensor input lines, respectively, and are 
driven and sensed by the DAC 52-' The sensor input lines 



62 may be optically . isolated input lines. The DAC 5 2 
outputs contact open and close signals over contact 
output lines 60. The DAC 52 monitors sensor input lines 
6 2 in order to detect a change in state (I.e. ..open or 
close) of a remote device. The remote device may 
represent a cart machine, a remote control terminal and 
the like. By way of example,, sensor inputs 6 2 may 
monitor a cart machine to inform the DAC 52 when a cart 
machine completes play of a local program. 

A user interface 57 may be provided to control the 
affiliate controller 46. By way of example, _the user 
interface 57 may include a keyboard, a mouse and a 
display, while the affiliate controller 4 6 operates in 
a Windows environment in whichicons may represent audio 
segments and/or programs, and functions (e.g., record, ' 
play, fade, stop and the like). The user may perform a 
desired function upon an audio segment or program by 
clicking,' dragging and dropping the associated icons. 

DIGITAL AUDIO CARD 

Fig. 6 illustrates a digital audio card (DAC) 52 
utilized in connection with the preferred embodiment of 
the present invention.. The DAC 52 may be implemented on 
a. printed circuit board 100 having an interconnection 
port 102 for connection with the mother board of the 
affiliate terminal 16. The DAC 52 may be implemented 
_^ i ^ h !L4il* ta _l processor (;DSP)_ 104 which, operates. . 

as explained below, while the preferred embodiment uses 
a DSP, it may be implemented with a dedicate chip or a 
general purpose microprocessor available commercially 
from Intel Motorola, CYRIX , AMD and the like.' Memory 
106 stores the command software which controls operation 
of the digital signal processor (DSP) 104. The DSP 104 
receives incoming data files and commands upon line ios 
(from lines 64 and 66 from the demultiplexer 50 in Fig. 
4).. The DSP 104 outputs decoded audio signals along 
line 110. The DSP 104 informs the affiliate controller 
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DAC EVEUTS BUFFER 

The DAC events buffer 166 stores messages of 
interest to the affiliate controller 46. By way of 
•example, the DAC event buffer 166 may store a. message 
indicating when an audio segment has ended 



and 
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, identifying the segment by event number. Optionally, 
the event buffer may store messages indicating when 
markers occur during playback of an audio segment. a 
marker may represent a flag preassigned by the producer 
5 at the production subsystem. As an audio segment which 

contains a marker is played, upon detection of the 
marker during playback, the DSP stores, in the event 
. buffer, a message indicating that the marker has 
occurred. Markers may be used to turn on and off 

10 contact closures. Thus, markers may be added to 

automatically control a local cart machine by 
'introducing a marker into an audio program. During play 
of the program, when the marker is detected, the 
affiliate controller 46 is informed of the marker and 

15 the affiliate controller 46 outputs a corresponding 

contact closure signal. By way of example, a marker #1 
may instruct -the affiliate controller 46 to close a 
contact, while a marker #2 may instruct the DSP 104 to 
begin a cross-fade operation. 

20 In addition, the DAC event buffer 16 6 stores sensor 

input messages received upon sensor, input lines 6 2 (Fig. 
4) by the DAC card. When the cart machine is instructed 
to. begin automatic play by automatically closing a 
contact, a sensor proximate the contact will detect when 

25 -'.the audio segment played by the cart machine ends. 

DAC PROCESSOR OPERATION 

-Next, the operation of the DSP 104 is explained in 
more detail. 

Initially, the data switch 12 0 monitors the line 1 
3 0 10 8 to determine when an input is present. . When this 

condition is satisfied, the data switch 120 accesses the 
incoming data to determine the DAC address therein . The 
data switch 120 compares this incoming DAC address to an 
■ address provided along line 122a from the card 
35 controller 122. If the DAC address of the present DAC 

corresponds ' to that of the incoming - data , the data 



switch determines that the i n( .„ • 

represents . / r ; up he ; dd t ss add " SS « th. incoming 
! h etermines the present da'c I 

;«>• *«up. The card controUe D r AC haSb6e " «s ign ed to 
-wit* »o of the group a *J e lZ *o T S ^ data 
fa een "signed, if the in, hlCh the n*C has 

DAC ' ::„ data ------- r:r- — 

When incoming data is 
" - containing ZZZTL* ^ P "~"* °*C 

. »o passes the data to o ! r l r T/- S " itCh 
128 based on a control 111x7 ^ 126 ™ 

122 " F-r instance, durl T" 1 the =ontroli er 

^ta s„ itch ^delivers Lo ^ op> «««>. 

»« to frame .urre 1 ; 6 "/^ 1 ; 9 audi ° along line 

frame buffer M6 delivers ^ mP ° r " y storage. The 

»«• *or decoding ^"^ iTj^ *° ^ d — 
The output of the decoder 150 ' 9 Si *" al " 

fc ° "-log converter to be * thr ° U * h 3 di *^ 

-timely output at ^ £ to nne 16 „ and 

Controller 46 as th= , J roni the af filiate 

broadcast. a " al ° 9 audio signal to be 

Alternatively, during ■ 
incoming data files pass thrn " °P er "i°«. the 

along U„ e i„ to the d ata h ? SWitCh 120 

-0 temporarily —ta buffer 

audio data along iine "1"- fll ° S until Passing tho 
ultimately to L memory Z7Z ^ ^ ^ " 2 ™ 
«■ Optionally, the ar/iiil a " iliate controller 

»4 via the card con^o ^Td"" °» DS? 

*«a along lines 128 and r 122 * incoming audio 

-y be recorded ( via data buffer Z ^ 

l"te„ ed to by the user ,v" f ^"aneously 

decoder ISO). ' frame buff " 146 and 



AFFILIATE CONTROLLER .. 

Fig. 8 generally illustrates a functional diagram 
of the modules of the affiliate controller 46 used in 
connection with the DAC 52. * The affiliate controller 4 6 
communicates with the DAC 52 via the virtual DAC .driver 
132. The affiliate controller 4 6 may be configured to 
include an audio server 18 0 having multiple internal 
modules that interface with DSP 104 (as explained 
above) . 

The audio server ISO may include an incoming data 
processing module 181 which processes data files (e.g., 
audio files, cart files,. play list files, video files, 
text files) received from the data buffer 13 0 (Fig. 7) . 
The incoming data processing module 181 stores these 
f iles on the memory 4 8 . The audio server 192 may 
include a card control module 182 for communicating with 
the card controller 122. The card control module 182 
and the card controller 122 pass command data 
therebetween, including requests, responses, polling 
commands and the like. An audio request processing 
module 184 may be provided to service data requests from 
the card controller 122. As explained below in more 
detail, the audio request processing module 184 obtains' 
da£a frames from the memory 4 8 and passes these data 
frames to one of the decoders 150 and 152 during a 
playback operation. 

_An ancillary data manager^ module_ 186 and event 
manager module 190 may also be provided to receive 
ancillary data and event messages, from the ancillary 
data buffer 164 and the event buffer 166, respectively. 
The ancillary data and event manager modules 18 6 and 19 0 
direct incoming data and messages to the appropriate 
module within the audio server 180 for "storage and 
processing . 

The audio server 180 provides control over 
playback, .sensor inputs, contact closure outputs and the 
like. The audio server 18 0 affords an interface with 
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affiliate users via communications link .188 . in this 
manner, the affiliate user may instruct the audio server 
180 to perform the above' discussed functions afforded by 
an affiliate .terminal. Optionally, the link 188 may - 
5 enable a remote control terminal 54 to input control 

request of the audio server 180, and thus to the 
affiliate terminal 16. 

The. audio request processing module 184 provides an 
interface between the audio files stored on the memory 

10 48 of the affiliate terminal and the DAC 52. As 

explained in more detail below, the audio_ request 
processing module 184 includes a buffer which stores 
data frames from an audio file stored on the memory 4 8 
in order to provide data frames from the audio .file to 

15 the DAC 52 . 

The audio server 18 0 provides a common point for 
all interface applications to : interact with the 
affiliate terminal. The audio server 180 represents a 
multifunctional server which enables users (e.g., 

20 interface clients), to attach thereto via several links 

(e.g., LAN , serial and the like). The users send 
requests to the audio server and receive responses 
therefrom via link 188. The audio server 180 manages 
multiple users accessing the same pool of affiliate of 
.25 'terminal resources (e.g., audio files, playback devices 
■such as cart machines, relay closures and the like). 
_ The Yj-^^^.P^^iX 61 " 121 P asse A da ta frames_from__ 
the DAC 52 to, the memory 48 (during a storage operation) 
and from the memory 4 8 to the DAC 52 (during a playback 

30- operation). The driver 132 also passes commands in both 
directions. In connection with the playback- operation, 
the DAC 52 signals the driver when the DAC 52 needs 
additional data.. The DAC 52 identifies the data by a 
■ unique identifier (segment handle) . 



PLAYBACK OP STORED SEGMENT 

Next, the discussion turns to Figs . 10a and 10b 
which illustrate the processing sequence followed by the 
affiliate controller 46 and DAC 52 in connection with 
the playback operation. The audio server 180 receives 
a playback instruction (such as from a user via link 188 
or from a remote device, via a sensor input 62). 
Initially, the audio request processing module. 184 is 
set to a read state to .wait for driver request, signals. 
The audio server 18 0 registers one or more audio 
segments with the audio request processing module 184 
(step 202) . To effect registration, the audio server 
180 passes, data file information to the audio request 
processing module 184 such as information in cart files, 
which may include a name of a data file containing the 
audio segment or segments to be played. In addition, 
the audio server 180 passes a start offset, and end 
offset into the audio file to the audio request 
processing module 184 . The data file information are 
passed as a. segment request to the audio request 
processing module 184 which stores the segment request 
on an audio segment table and assigns a unique segment 
handle (e.g., a unique number) to the segment request. 
T^e segment handle is stored with the segment request in 
.the audio segment table (step 204) . 

The audio request processing module 184 returns the 
unique _segment handle to_ the_ audio server 180. 
Thereafter, the audio server 180 passes the segment 
handle and additional control information to the DAC 52 
as a load segment information request signal (step 206) . 
The additional control information may include, for 
example, an identifier designating which of the decoders 
are to be used, segment start options, start fading 
time, end fading time, event markers, a start trigger 
and the like. The load segment request is. passed to the 
card controller 122 (Fig. 7) and the card controller 12 2 
stores at least the unique segment handle. 
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At step 208, the DSP 104 returns a request audio 
data message including the segment handle to the audio 
request processing module 184. upon receipt . of this 
message, the audio request processing module i 84 
accesses the audio file identified in the audio segment 
table by the segment handle (step 210). The audio 
request processing module 184 reads a set of data frames 
from the audio file and transmits these data frames to 
the DAC 52. At step -212 , the audio request processing 
module 184 waits for a next data request from the DAC 



52. 



Turning to Fig. 10b , the DAC 52 loads, ^he data 
frames received from the audio request processing module 
184 into an input buffer of the designated decoder (step 
214). The DAC thereafter waits for a start message 
before beginning the decoding operation. At step 216 f 
the audio server 180 sends a decoder play request to the 
DAC 52. The decoder begins decoding and outputting the 
digital audio signal (step 218). When the decoder has 
completed decoding a predetermined portion of the data 
frames in the decoder input buffer, the DAC 52 issues a' 
request audio data message to the audio request 
processing module .182. At step 220, the audio request 
processing module 184 reads the next set. of data frames 
25 from the hard drive and writes this new set of data 

■frames to the DAC 52. The audio request processing 
module 184 again enters a wait state to wait for a next 
data .request "from" the DAC 52. Steps 218 and" 22 0 are 
repeated until the desired segment or segments from the 
30 audio file are read by the audio, request processing 

module 184, passed to the DAC 52 and output as audio 
signals or until user intervention. 

At step 226, the DAC 52 issues an end of segment 
event when the last data frame stored i„. the decoder 
35 input buffer is decoded and played. Upon receipt by the 

audio request processing module 1S4 of the end of 
segment event, the. audio request processor (at step 228) 
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clears the last set of data' frames from its buffer and 
closes the audio file. In addition, the audio server 
180 perforins any additional processing . which is 
necessary upon completion of the playback operation of 
5 the audio segment. These additional operations may 

include cleaning up tables, notifying user, closing and 
opening contact relays and the like. 

AUTOMATIC PLAYBACK OP LOCAL SPOTS WITH STORED SEGMENTS 
Next, an example is described whereby, during 

10 playback of an audio program stored on the memory 48, 

local audio segments are automatically played by a cart 
machine. The audio segment stored on the memory 48 is 
played by the DSP 104 according to the playback 
operation described above. By way of example only, the 

15 stored audio program may include two audio segments. 

(national segment #l and national segment #2) which are 
to be separated by two local . segments (local segment #1 
and local segment #2). 

Initially, national segment #1 is read from the 

20 memory 4 8 and supplied to the DSP 104 in sets of data 

frames. A marker attribute is assigned to national 
segment #1 indicating that a contact should be closed 
upon completion of the national segment #1 in. order to 
start the local cart machine (which containsthe local 

25 .segment #1).. As the DSP 104 processes the first 

national segment, it identifies the marker attribute, 
after the appropriate offset time, writes a marker 
attribute message to the DAC event buffer 166, such as 
the marker number. The affiliate controller 146 reads 

30 the marker attribute message (marker number) from the 

event buffer 166 and, responsive thereto directs the DAC 
52 to output a contact closure signal upon line 60 (Fig. 
4) instructing' a first cart machine (containing local 
segment #1) to begin play. The DAC 52 then polls a 

35 sensor input line 62 from cart machine 1. Upon 

completion of the local segment in card #i, the- cart 



machine is stopped and a contact open signal is returned 
upon sensor input signal 62. The return signal from 
sensor input 62 informs the affiliate controller 46 that 
the cart machine is either completed play of the local ' 
segment or about to complete play of the local segment 
(e.g., within the next. 30 seconds). Responsive to the 
input, along sensor input line 62, the affiliate 
controller 4 6 instructs the DSP 104 to begin play of the 
next national segment #2. The affiliate controller 4 6 
loads the national segment #2 into the DSP. 104 in the 
manner explained above upon completion of the first 
local segment. " . 

In the present example, a marker attribute #2 is 
assigned to national segment #2 indicating that a second 
local segment should follow completion of the second 
national segment. As the DSP 104 processes the second 
national segment, the DSP 104 writes the second marker 
attribute, message to in the data event buffer 166 at a 
predefined time during play of the second national 
segment. The affiliate controller 46 reads the second 
marker attribute from the buffer 166 and instructs the 
DSP 104 to output a second contact closure signal upon 
line 60b. The contact closure signal upon line 60b ' 
instructs a second cart machine to begin play of a 
■second local segment. As above, when the. second cart 
machine reaches the end of a second local segment, the 
Se _ CO I^ _ c ^. t J n ?^ h . i J? e __ ?l_ t P" t . ! ? a . sensor input.. signal, upon 
line 62b instructing the DSP 104 that the second local 
segment, is complete. Optionally, the second cart 
machine may supply the sensor input along line 62b a 
predefined, period of time before completion of the 
second local segment ' (e.g . , 30 seconds). in this 
manner, the affiliate controller . 4 6 may automatically 
cross-fade national and local segments. 



CROSS FADING 

Fig. ll illustrates a block diagram- representative 
of a cross fade operation between two audio segments 
stored in memory 48, followed by a local spot played by ' 
a cart, machine. For purposes of this example, it is 
assumed that the play list includes the following cart 
fil'e names and instructions on when to begin play of the 
cart file: 

Segment #1 - Start Option, Manual 
Segment #2 - Start Option, Marker 2 
Local Spot #l - Start Option, Marker 1 " 
It is further assumed that the cart files for 

segments #l and #2 and local spot #1 include at least 

the following attributes : 

' , Segment #1 

Start Offset 0 
End Offset 2000 
Marker 2, 1900 
Audio File Name #1 

Segment #2 

Start Offset 400 
End Offset '3 000 
Marker 1, 3000 
Audio File Name #2. 

Local Spot #1 

. Contact Closure, Cart 1 
Sense Play End, Cart 1 

Returning to Figs ... 7 and 8, during operation, the 
audio request processing module 184 initially passes to 
the- card --control ~122 - the ~ segment — handle and 
. corresponding list of attributes for segments #1 and #2 . 
Segment #1 extends from location 0 through 2 000 in audio 
file #1 (e.g . , each location may correspond to a data 
frame) . Segment #2 extends between locations 4 00 and 
3000 in audio file #2. 

The audio request processing module 184 obtains a 
first set of data frames for segments #1 and #2 from the 
memory 48 and passes the sets to the card control 122. 
The sets of data frames are stored in buffers in the 
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first and second decoders 150 and 152, respectively. 
The first decoder 150 begins processing the data frames 
from segment #1. The audio request processing module 
184 provides new data frames from segment #1 as needed 
by the first' decoder 150. When the first decoder 150 
reaches location (e.g., data frame) 1900, the DSP 104 
detects the Marker #2. Responsive thereto, the second 
decoder 152 begins decoding the first set of data frames 
from segment #2. In this manner, the first and second 
decoders 150 and 152 simultaneously output digital data, 
as shown in Fig. 11 at cross fade region 500. _ in the 
cross fade region 500, the mixer 158 reduces the 
amplitude of the audio segment #1 and increases the 
amplitude of the' audio segment #2 to nix the two segment 
outputs as provided to the broadcaster at point 160 
and /or to an AES/EBU output. 

Optionally, a second marker event {e.g., Marker 1, 
1600) may be added to the cart file for segment #1 to 
instruct the mixer 158 to begin reducing the amplitude 
20 of segment #1 before reaching the cross fade region 500. 

In this example, mixer 15S would begin reducing the 
amplitude of segment #1 at point 504 (as shown by line 
506). The second decoder 152 may then begin segment #2 
. at point 508 and the mixing operation may then continue 
25 * s . explained above. 

With continued reference to Fig. 11,. the second 
_ decpder_ 152 —continues, .processing- segment ■ -#2-_ unti-1 
reaching location 3000. Location 3000 corresponds to 
the end of the segment #2 and to Marker #1. Marker #1 
30 is stored in the event buffer 166, along with the 

corresponding segment handle. The event manager module 
190 relays this event message to the audio server 18 0. 
Responsive thereto, the audio server' 180 returns, via 
the card control module 182, an instruction directing 
3 5 the DAC 52 to output a contact closure signal over line 

60 (Fig. 4) to cart machine tl. The contact closure 
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signal instructs the cart machine #1 to begin play of a local spot #1. 

The audio server 180 then continuously polls the DAC 52 to determine when a 
sensor input signal is received along line 62 from the cart machine #1, The sensor input 
signal indicates that the local spot has completed play. The DAC 52 informs the audio 
server 1 80 upon receipt of the sensor input signal. The audio server 1 80 continues play 
based on;the next cart file in the play list. 

ARTICLE DELIVERY SYSTEM WITH HUB TERMINALS 

Fig. 12 generally illustrates a block diagram of an alternative embodiment for the 
article delivery system. The article delivery system 600 includes at least one producer 
subsystem 602 which operates in the mariner described above to produce data files. 
Optionally, producer 602 may assemble the data files into an envelope and pass the 
envelope along line 618 to hub 604. Each envelope may be structured as set forth below 
in the section entitled ENVELOPE FORMAT. Each hub may include the above 
described structure of an affiliate terminal. In addition, each hub 604 includes an 
envelope distribution management system for routing incoming envelopes. Each hub 
may include a satellite receiver as described above and/or one or more communications 
links which support the transmission of digital data, such as ISDN links, conventional 
phone links and the like. 

Returning to Fig. 12, when hub 604 receives an envelope from producer 602,. the 
hub 604 reads the address information within the envelope and routes the envelope 
accordingly. If the envelope is directed to the hub 604, the hub 604 operates in the 
manner described above in connection with an affiliate terminal to store and playback 
received data files. If the envelope is directed to ISDN affiliate 606, the hub 604 
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routes the envelope along i ink 620 to the JSDN . ^ 
Optionally, ISDN aff il ia tes nay be configured"' 
the Banner described above in correction with aLiUate 
ter» lnals 16 , but, relying on ZSDN links £or receipt "nd 
J"— «- o, envelopes, xive data stream a „a £ 

^ The hub 604 may also route incoBing envelopes tQ a 
Master upun, hub 608. Hub 608 nay indlude J ^ 
"c^ty, such as described above in connection with t£ 
delivery subsystem 14. The hub 608 may transit Hi 

The satellxte 6 10 transmits incoming envelope along 
aovnlxnks 626, 628 and 632 . sateliite affiUate 612 9 
resemble a ffil iate terminal 16 . Sat-Uit . afmiate fi J 
may process incoming envelopes as affiliate terminal 16 
described above. Hub 614, upon receiving an envelope 
«y route the envelope to ISDN affiliate 616 if i SDN 
«« Hut. 6X6 is identified in the address inforaation 
withm the envelope. 

" Satellite 610 may transmit all incoming envelopes 

■to all hubs, satellite affiliates and the like within 
the satellite's line of sight. Upon receipt/each hub 
and satellite affiliate accesses the envelope to 
identify the address information therein. If the 
.-elope is addressed to tne receiving satellite 
affiliate and/or hub, they proC ess the envelope 
" COrdl _ n ?iY • . the envelope is_ addressed - to a hub-or 
«DN affiliate connected to a receiving hub, the 
receiving hub routes the envelope thereto. However 
when a satellite affiliate or hub receives an envelope 
not addressed thereto or to a hub or affiliate connected 
to the receiving hub or satellite affiliate, the 
receiving satellite affil iate or hub disregards the 
envelope. 

By way of example,- when producer 602 generates an 
envelope directed- to satellite affiliate 612 • the 
envelope is passed to hub 604 which determines that the 



envelope is _not directed to hub 604 or affiliate 606. 
Consequently, the hub 604 passes the envelope on to a 
hub 608 which may represent a master satellite uplink 
hub. The master satellite uplink hub 608 relays the 
5 envelope via the satellite ' 610 to all. satellite 

affiliates and hubs having satellite receivers. Hub 614 
receives the envelope and determines that the envelope 
is not directed to hub .614 or ISDN affiliate 616. 
Consequently, the hub 614 disregards the envelope. 

10 Satellite; affiliate 612 receives the envelope and 

determines that the envelope is directed to satellite 
612. Responsive thereto, the satellite affiliate 612 
processes the envelope in the manner described above. 

Optionally, all hubs may includes satellite 

15 receivers. 

ENVELOPE FORMAT 

Each envelope may be constructed from multiple data 
files and the like that are divided into records. Each 
record may include a unique I.D. associating the record 

20 with its corresponding envelope. in addition, each 

record may include a producer subsystem I.D. identifying 
the production subsystem at which the envelope was 
produced. The producer and envelope I.D.'s enable 
unique identification and tracking of every envelope 

25 through the delivery system. 

.. Optionally, each_ envelope may include a routing 
path record containing a list of hubs and affiliates 
through which the envelope has been routed. The routing 
path record is updated by each producer and affiliate 

30 which receives and routes, the envelope. ■ By way of 

example only, when producer 602 produces an envelope, 
the routing path record begins empty. As the envelope 
is passed to hub 604, the .I.D. of hub 604 is added to 
the routing path record. . This process is repeated until 

35 the envelope reaches its destination. Thus, envelopes 

travelling from producer 602 to affiliate 616 would 



include i„ the routing path record, upon delivery at the 
affiliate 616, a /list containing the hub I.D.'s of hub 
604, master hub uplink 608, and hub 614. 

The routing path record may be utilized by the 
system to prevent circular routing through a single hu b 
By way of example, it is assumed that hub 604 includes 
a satellite receiver to receive satellite transmissions 
from satellite 610. 

Next, an example is explained whereby circular 
routing is prevented through the use of the routing path 
record. The producer 602 produces an envelope directed 
to satellite affiliate 612. The envelope passes" through 
hub 604, hub 608 and satellite 610. At this point the" 
routing path record has been updated to include the hub 
I-D's of hub 604 and hub 608. When satellite 610 
transmits the envelope, affiliate 612 and hubs 604 and 
614 receive the envelope. Hub 604 accesses the routing 
path record and determines that the envelope has already 
been routed through hub 604. Consequently, hub 604 
disregards the envelope and does not reroute it. 

DELIVERY VERIFICATXOH 

Optionally, the delivery system may include 
delivery verification. According to- delivery 

.-verification, when a package is sent to an affiliate, 
the producer is provided a tracking number. At the 
producer's option he may create -work orders" which 
permit him to group several different envelopes (each 
with different contents and delivery addresses) into a 
"group" with a user supplied designation. ' The work 
order is simply a way for a user to track sets of 
envelopes which could, potentially, have been submitted 
at different times. The producer is given a piece of 
software which can be used from any modem equipped PC 
which permits him to call an 800 number to check on the 
delivery of his envelope. As part of the billing 
system, the user is provided with details of which 



envelopes were delivered and when and which ones were 
undeliverable. . The software provided to the producer 
will permit the management of many outstanding packages 
each addressed to many recipients. m addition 
information may be retrieved by work order designation 
as well. Access to the system may be either by dial up 
direct (800 number) or via the Internet. The delivery 
verification system of fers the following functions. The 
system . offers centralization of delivery status 
information. The architecture of the system is 
decentralized, yet the producer may want to contact a 
single location of find out the status of his envelopes. . 
The delivery information may be centralized. The system 
offers shared delivery status information. The delivery 
status data base may be shared between a number of "back 
office" applications. Some potential users of this data 
base include: 

# records* ^ USed t0 9 enerat e billing 

Quality control. Retrospective studies to 
determine performance may be made usinq this 
information. ' , ■ ' 

Tracking. Users may call up and request help 
with finding where their envelope is and whv 
. it did not arrive. 

The status data base may be predictive in that users may 
must be given accurate predictions as to when delivery 
wi Ak ?ccur ._ Predictions _can-.be- updated-as the delivery- 
becomes emanate. The tracking system may be able to 
deal with different methods of delivery and the 
associated mechanisms for delivery verification. Each 
delivery may potentially have to pass through several 
different states as it is delivered (sent to a hub, 
entered into FedEx, delivered) . Each delivery facility 
has different verification requirements: 

• ISDN: Verified at the time of delivery by the 
sending side.. J 
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5 * FedEx: The FedEx system may be mieri»rt «- 

of the package was WesslullVde^verld ' 
• Combination: Some deliveries 

^ of the above. Verif icatioi £S co =*ihations 

lost and mult trac*^ T^^?"" 

successfully delivered lotion* * laSt 

DELIVERY VERIFICATION ARCHTTECTDRE - 

15 n. * d6liVery StatUS =^P«ter (DSC) is defined. The 

DSC may be communicated with via Tcp/Ip eroa e . ther 

local LANs, dial up via Microsoft's WkS 'facility or from 
the internet. The DSC maintains a shared database which 
is a ccesses via ODBC. The database stores the. status of 
"1 of the current and historical deliveries in the 
system. All packages may be assumed delivered tQ ^ 
This simplifies the design of the system and permits 
control over the receiving resources of any given 
affiliate. In this manner, administration may. maintain 
control over the scheduling of .affiliate communications 
resources . 

When hubs receive envelopes, they examine the 
envelope's address, label and produce a "shipping list" 
. . Whlch _ is _ forarded to_ the .DSC. . The _ shipping . . list _ 
contains all the information, from the envelope to 
maintain the delivery status database at the DSC. This 
includes: 

• Envelope's tracking number. This number i, 
I^rlducL 3 ^"^"" desi ^"cr "nig^amonl 
unia^^trinat^roaucir 10116 ™ r ^ 

' proai^r! 8 En9Ush naBe ' ^ the 

n^^o'K 63 ^?. 11 - 0 " 8 to «hich .the envelope 
needs to be delivered. 
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• Any work order' to be associated with the 
envelope. 

• Date and time the envelope was received at the 
hub. 

The shipping list may be sent to the DSC regardless 
of how the hub determines the envelope should be routed. 
In other words the shipping list is sent to the DSC even 
if the hub determines that the envelope does not need to 
be sent to the uplink hub (all local delivers). The 
shipping list may be sent, to the .DSC either via dial-up 
RAS or Internet. In either event the TCP/IP protocol 
may be used so that the receiving hub has positive 
completion assurance for the delivery of the. shipping 
list to the DSC. The DSC uses the shipping list to 
construct entries in the delivery status database (DSD) . 
If necessary the DSC sends alert messages to other back 
office applications who have "registered" with the DSC 
to indicate changes to the DSD. The DSC uses 
information in its databases to determine how. the 
envelope will be delivered to its various destinations. 
This permits it to determine initial delivery estimates 
and to set up a "state diagram" for each delivery event. 
One entry for each delivery event is made into the DSD. 
A * delivery event is a single envelope/destination pair. 
The state diagram tracks the transition of the envelope 
along the logical route required to deliver it {e.g. 
Uplink tb~satellite -to- Wilmington -to- FedEx to delivery! 
The system may support the following routes: 

• Satellite direct: Uplink hub to affiliate 
directly via satellite. 

• ISDN direct: The ISDN affiliate is located in 
the same area is the post office hub which 
received the envelope. 

• Satellite to ISDN: , The uplink hub delivers 
the envelope to a hub which, in turn delivers 
the envelope to the affiliate. 

• Off line: Uplink hub to Wilmington affiliate 
to FedEx to destination. . 
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Each leg of the delivery path may reports 
completion. The mechanism used to report completion may 
be either active (some element of the delivery process 
actively reports' completion to the DSC) or passive (the 
5 DSC must take some action to determine completion) . The 

mechanism to . determine completion . depends on the 
delivery technology. The following are supported: 

ISDN: The sending (hub) reports that the 
10 envelope was successfully delivered. The 

reporting is done directly to the DSC 
Reports are batched together - failures are 
reported immediately. 

Satellite: A" special polling technique 
described below is used. 

15 * FedEx: The FedEx computer are polled by the 

DSC to determine completion. Polling is based 
. on the FedEx estimated delivery time along 
Divine Guidance and fasting. 

The DSC may receive calls from the producers and 
20 other interest parties and provide a TCP/IP based 

protocol to enable callers to query and DSD for 
information pertaining to the delivery status. The DSC 
may- receive messages from other back office applications 
.telling it to perform housekeeping chores on the DSD. 

2 5 SATELLITE DELIVERY VERIFICATION 

The delivery of satellite based envelopes may also 
be verified even though the satellite may be a send only 
medium. - in' this- instance, "there is no" back channel" to 
permit receivers to report if they do not receive 

30 information properly. If a large number of potential 

receivers are used, it may not be desirable - to simply 
pol to determine if delivery has been effected. The DSC 
may use a different type of polling scheme. Generally 
satellite "delivery is successful, only the receiver is 

35 aware if it has received the envelope or not. Envelopes 

may be partially received with' only parts missing. 

As a result of the above the DSC implements the 
following verification scheme. At a regular well-known 



interval the DSC scans its 

constructs "inventory packages" whi „ ° SC 

: nv el o P es which have p bee r r s ece: h t r :^rU ists T r 

inventory packages are sent Qei ^ered. . The 

are Messed receive the inventory tt ' 
their inventory with the invento^ in tT " 
there is any discrepancy the ^ .*■«*•»•• " 

to can the Resend Managed ^ J?" ^ lW 
discrepancy, then the «t\LTL " **** " "° 
ti-e during the rece P tL n of ^ ^ " ^ 

affiliate deterges that it his J " nV * 1 ° P ' ; r" «» 
a record is in error " J"" B1 "" d a that 
„««,.,. e "?r, it contacts the rsm if th „ 

affiliate does not receiv. ■ 

fr stations who have not received envelopes), then it 
calls the RSM. When the dsc ^ 

Packages with the sa me me in " ^ 

„ v ^ ■ , . 111 and doe s not receive 

-y co mp l aints frora stations> ^ x • 

delivered. The delivered files are no longer include'* 
in subsequent inventory packages. included 

DISTRIBUTION STATUS DATABASE 

to de^ ° S \ iS * " USCti0n ° £ "hich »ay be used 

folio St " US ° f th& delive ^ Proc«..- The 

following. tables are defined: 

1- Affiliate database. This h K u 

-te^iagra, wh/ch vtll^e used^r^ ST 

phone nuaber, naae contact, j£° ducer ad ^s, 

3. Delivery event database. This 

contains an entry for each h.h dat abase 
includes the foXolYng Vol^nir ^ SVent - 



Envelope identifier, 
producer number. 



This includes the 



the 



Destination designation. Where 
envelope, must be delivered to. 

highest priority envelopes ar/ ^? e i 

Work order designator, 
and supplied by user. 

Current status. 



This is optional 



Current best estimate for delivery. 

State within the delivery state diagram. 

Additional, stuff required by the DSC to 
execute its completion algorithms. 

REMOTE CONTROL TERMINAL 

Fig. 5 generally illustrates a perspective view of 
an exemplary remote control terminal, such as an on air 
interface. The remote control terminal 58 provides 
remote control of the affiliate, terminal, such' as from 
within the DJ's booth. The remote control terminal 58 
may offer all functions available at the affiliate 
controller 46, or only a subset thereof. By way of 
example, the remote control terminal 58 may be concerned 
only with^on air production of a given play list. The 
remote" control " terminal " 8 includes'a display 70~ and 
control keys 72. The control keys may enable the on air 
operator to select from several different audio 
selections within a given play list and the like. The 
affiliate controller 4 6 determines which of the audio 
selections may be displayed to and selected from by the 
on air operator at the remote control terminal 58. 
Generally, without intervention by the remote control 
terminal 58, the playback of audio segments from within, 
a program are sequential based on the play list. The' 



remote control terminal 58. enables the on air operator 
to override the normal sequence of *he audio segments by 
selecting audio programs out of sequence. 

The control keys 72 may include up down arrows to 
5 enable the on air operator to select a desired program 
from within a play list. The keys 72 may also include 
start and stop keys to begin and end the playback of the 
next or desired audio selection. The display 70 may 
display a countdown timer which counts to the end of the 
10 present event being played; The display 70 may provide 
outcues for the current audio event. . The display 70 may 
display some or all of the play i ist information-used to 
. control the present program, including the f ormatics 
associated with each audio file. 

Sensor inputs 62 may monitor the remote control 
terminal to obtain play back requests from the DJ. in 
this manner, the DJ may request that the DAC 52 play a 
program out of sequence from the normal play back list 
sequence. The DJ may also request, through the remote 
control terminal, that the DAC 52 start play of the next 
segment queued" in the DAC 52, stop play of the current 
segment, fast forward/rewind through the current segment 
or to a next/previous segment. The DJ may use up/down 
arrows on the remote control terminal to scroll through 
a play list displayed to the DJ and select, out of turn, 
a segment from the play list. The DJ may also, audition 
segments by selecting an audition, option communicated, to 
„the_DAC 52_via.the sensor inputs-62-. 

AFFILIATE AUDIO -SERVER 

The affiliate terminal supports multiple interfaces" 
with different users, including interfaces with a 
program director, an on air DJ, traffic users and 
foreign systems. The program director interface is 
offered via the affiliate controller 4 6 to provide all 
of the functions available by the system to the. program 
director. .The on air DJ is afforded access through a 
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remote control terminal 54 and may be offered a limited 
function set, such as play, stop and audition of 
programs from a play list. Traffic users are interested 
in inspecting documents pertaining . to the availability 
of local program spots. Traffic users may be given no 
control over the playback of audio, but instead may 
simply be afforded the ability to view play lists and 
the like. Foreign system users may access the affiliate 
controller through RS 232 ports, local area networks and 
the like. Each of the foregoing users communicates with 
the affiliate terminal through the audio server 180 
(Fig. 8). The audio server identifies the type- of user 
and the set of potential functions- to which that user 
has access . Each of the above types of users may 
communicate with the audio server through one or more 
protocols. By way of example only, communications 
between users and the server may be via a TCP/IP socket 
and the like. The TCP/IP channels may support 
transmission of ASCII text and binary data. 

The audio server 180 operates with a number of 
different objects. Users are afforded access to objects 
via the protocol. For. example, one object may be a 
player. Protocol messages permit a user to enumerate 
the players in the system (e.g., how many of them there 
are), load audio into the players, start a' player 
playing and the like. 

Each object has a state associated with it. Some 
state" information "persists 7 from boot up" to~ boot up 
(persistent state .information) while other state 
information must be set each time the audio server 
begins execution (temporary state information) . An 
example of persistent state information is the 
association of a given player to a. given studio while an 
example of temporary state information is whether a 
given player is actually playing or not. some of the 
protocol messages change the persistent state of objects 



while other messages change the temporary state of 
' objects. 

Persistent objects have . files which contain the 
object's state information. The files may be ASCII 
5 format files. Each record in the file may include a. key 

word and a value. 

Audio server users may connect to the application 
by building TCP/IP connections. Two paths may be built 
to the server, namely a message path and an event path. 

10 The message path may be bidirectional and may be used 
for communications between the interface client and the 
audio server in a "master slave" mode. The interface 
client may be the master/ and may send a message to the 
audio server. The audio- server may send a response 

15 back. As to the event path, objects may need to send 

messages to the interface client to alert the client 
about events and conditions within the object (e.g., the 
player has run out of audio, the user has pressed a 
. button, and the like) . These messages are sent via the 

20 interface clients event path. 

Ob j ects may also represent "container" ob j ects . 
These objects contain other things, for example, a -"tape 
rack" is a. container object which contains audio files. 
Play list and cart files. A play list may be. a 

25 ■ container which contains a list of the audio segments 
which make up the play list.. " The container may be 
implemented as a . file directory. The desktop may 
. represent, the highest directory. - When- a user "is logged, 
into the system his current working directory may 

30 . represent the desktop. This may be moved to other 
directories' in order to enumerate objects in that 
directory. 

Objects are "opened" before they may be referenced. 
Opening an object is performed with the OPN message. 
35 when references to the object are completed the CLO 
Message will close the object. . An object may be opened 
in either read-only mode or read/ write mode. Any number 
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of users may open an object in read-only mode but only 
one user may open the object in read/write mode. 

Below are set forth a list of messages which the 
audio server may implement. 
Called: CON <user password> 
AOK <handle> 



Returns : 
Comments : 



This call win set up a connection between the 

S! r ,^? rt aUdi ° se . rver * T he return from 
the audio server provides a handle which the 
user can use to set up an event path back to 
the application from the server. The event 
path is used to process synchronous events . 



Called: 



Handle returned f rom^ the CON 



Coirunents : 



EVN <handle> 
call.- 

This call will create an synchronous event 
handle which the audio server uses to transmit 
messages to the . interface client . 

tfi!^ . [ i" a ; e> ! °P tional English version of rack 

»L5 «.u hat lf not su PPlied then the desktop is. 

used as the source for objects. 

Response: ERR or AOK <name> <type>; 

<name> Name of the element. This is the "English 
name" not the file name. It is enclosed in quotes 
and may contain spaces. This name may be used in 
other calls to reference the object. Where used in 
this fashion it must be reproduced exactly as 
returned here. 1 



<type> The type of the element (e.g. 
Playlist, Player and "Log. 



Cart, Rack, 



Comments : 



Called: 
Returns : 

Comment : 



This function returns the first element in the 
current, wprking;_directory . ■ . It -is - normally 
followed by RNE (read next element) requests 
in order to establish the contents of the 
current working directory. Note that the 
. content may change as a result of received 
audio and other user interactions. These 
changes. are sent to the user via events over 
the "event path" in his connection. 

RNE 

ERR or AOK <naae> <type> See rfe for 
definition of AOK • arguments 

Returns the "next" element in the directory. 



30 



NOTE 



Called: OPN <how> <name> < t ype> {<container><type>> o-n 

<how> How to open the object (e.g. read on5v ™^ 
or read/write mode). i e *9. ,. read only mode 

<name> English name of the object to open, 
^ist,^^ ^rt, Ra ck, 

<container> Optional "container" name. 
<type> Type of container (e.g., rack or playlist) . 
The <container>ctype> argument may be repeated 

Returns: ERR or AOK <handle> 

Comments: This function opens objects possibly for 

fhandie e i^^ If ? e ° p£n iS ^anted^ t££ 
a handle is returned to the object which mav 
be used with function, which require a handle 

the handle has no further meaning when the 
user logs off or when he issues a CLO command 

Called: HAS <enamextype> ; 

<ename> English name of the desktop object. 

<type> Type of object. 
Returns: AOK <content> or ERR 

Comments: This is primarily used to check to see how -a 
* nt f rface object should be drawn if the 
object is drawn differently based on its 
content. 

Called: CLO<handle> 

regues?! provided b * a successful OPN 
Response: AOK or ERR 

Comments: This function releases the opened object. 



Called: 



RIN <handlexkeyl> ... <keyl> 



52 - 



10 



15 



20 



<handle> OPN Handle to the object. 

<keyn> Keyword (s) to read. 

' Returns: err if ■ there is an error or 
AOK <valuel> ... <valuen> 

<value„> The current value Qf tte requeste - d 
called: ^handlex^xva^el,. . . . <tay hx w i Mn> 

<keyn> Keyword of value to update. 
<:valuen> Value of the keyword to change. . .. 

Returns : AOK or ERR 

counts: Not an readable Keywords ' » ay . be changed. 

Called: IRP <object> 

^ SCt « °P ened objected who's play list is to 
play'lis C tf rently tMS Can be ^r^l^ r % h t 

Returns: AOK or ERR ' 
Called: rpr. 

Returns: ^ ^andlextypexaro^entsXsee consents) 

Remark: rem <reaark> 

' Se*p!ay list*." 9 Whi<=h contains about 



On Air Note: ONA <remark> . 

the m play list"* °° n1:airis a reinar * about 

Start Track: trk <title><playtimexoutcue> 

<title> Title associated with the track 
This is usually something like "Seg i- but can 
be as imaginative as required. 

<playtime> Length of time the track plays in MS. 
<outcue> The track's out cue. 
End Track: ENT 

End of track - 
Cart: CRT <type><title><playtime><outcue> 

t*ll &> r« H ° W is USed in this tra <=k of the 

show (e.g., commercial, program).. 

1t L li e> , En ^ h title «<?r the cart. A cart file 
in the play list directory must match this title 
for the- cart to be found. 

<playtime> Time cart plays in MS. 

<outcue> Cart's out cue. 

Local Break: BRK <time> 

<time> Duration of local break in MS. 

Called: GPS<player> 

<player> . OPN handle of the player to get status 

Returns: ERR or 

AOK <statexloaded><cur> 

<state> The current state of the player (e.a. , 
playing, stopped) . 1 K y '- 

<loaded> Indicates if the player is loaded or 
empty: 

1 Loaded 
0 Empty " 

<cur> Handle of the current radio. 



Called: LOD<player><elementxtype>[<location> ] 

<player> OPN Handle of the player to load to. 

<element> ASCII name of the element to load on the 
player. This must be either a cart of a play list. 

5 <type> Type of element to load (e.g., audio cart 

, audio play list). ' 

<location> Location to load element in player's 
stack. This is optional. if not provided, it is 
the ordinal position to load to with the first 
10 position being 0. 

Returns : AOK or ERR ■ 

Comments: The elements which are loaded must be on the 
desktop. Note that once an element is loaded 
into the player, it no longer appears on the . 
15 desktop. It is moved into the player's 

directory. ' 

The player must be opened with write access In order to 
execute this command. 
, Called: PLY <player> 

20 <player> opn Handle of the player to start 

playing. Must be opened in read/write mode. 

Returns: AOK or ERR. Event is sent at end of current 
element. 

Comment: Players have multiple audio elements in them. 
25 ' Once they start playing one audio element 

after another. 

. Called: CUE <player> . . 

<player> OPN Handle of the player to cue audio on. 
Player must be opened in read/write mode. 

30 Returns: AOK or ERR. 

Comment: The CUE function reduces the latency of the 
PLY operation. If you do not do a CUE then a 
CUE is implicit with the PLY. If you perform 
a CUE then the, PLY will execute much faster. 
35 The latency^ between the PLY and audio playing 

is a function of the current player's play 
list. 



Called: STP <player> 



<player> OPN Handle of the player to stop. Plaver 
must be opened in read/write mode. ^xayer 

Returns : AOK or ERR 

5 Comment: Causes the specified player to stop playback 
at its current point. Issuing a play vill 
cause the player to continue playing fro* 
where it was when stopped. 

Called: REM <player>[<player>] 

10 <player> OPN Handle of the player . to remove an 

element from. Player, must be opened in read/write 
mode . 

<player> The handle ' of the element to remove. 
Note that this argument is optional. If omitted 
^ the "first" element is removed. 

Returns : ERR or AOK 

Comments: This function permits the client to remove 
elements from the players stack. 

Called: SCE <player><handle> 

20 <player> Opened player handle. 

<handle> Handle to element. Gotten from the read 
play list thing. 

Returns: AOK or ERR 



Comments: This establishes the current element for the 
player. The next play or_ audition operation 
will ~ref erence this element. 



Called: RCE <player> 

<player> OPN Handle of the player. Player must be 
opened in read/write mode. 

Returns: ERR or AOK <handle> 

<handle> Unique handle assigned to the element. 
Note that this handle is unique and will never 
change until the system is rebooted. 



- Cedents: i his provides inforn 

location in the Pl«yS?S p" ty °S ta «£' ,<=«rent 

c a iie d: Aro <pi ay er><end> 

Wr^fZ openel £f r^/fe - -^on. 
SS-^ES re:- «" — .W to audition. 

element's start; and to the 

n: Audition last »ntt - 

Response : AOK or ERR . 

died: MTR ^leaentxtypexraOo 

<element> The Encni^K 

desktop to KoVtUte "I™*"* the ele »*"t on the 

sr^p^ p^^.- -e {e . g ., 

-** 2 a ?o^v n tt is d h es rop. fOT the rac* 

Returns: AOK or ERR ' ' . 

Called: MFR <rac ^ c>< elementxtype> 

• Thti: rack 

<element> The EnrrH^ 

desktop to .ove^the ract^ the dement on the 
<typ e > The type of P i e ™ ant . ^ 

rack, Playl ist ? e pl ^ e ^ e ^ ^o move (e . g ., car ^ 
Returns: AOK or ERR . 

Called: del <ele ffl ent><type> 



<element> The English name of the element to 
del etP 



delete 

<type> The type of the element to delete (e.q. 1 
cart, rack, playlist, log) . . 

Returns : AOK or ERR 

Called: MKR <name> 

<name> English name for the. rack. 
Returns: AOK or ERR 

Comments: This function checks for duplicate names and 
does not allow them. — 

Called: CEN <old-namexnew-name><type> 

<old-name> Old English name of element on desktop. 

<new-name> New English name of the element on 
desktop. 

<type> Type of element .(e.g., cart, rack, 
playlist, player, log). 

Returns: AOK or ERR 

Comment: This function checks for duplicate names and 
does not allow them. 

EVENT ARCHITECTURE 

Often the server must send information to one or 
more clients connected to it. For example; . if the 
server deletes a given ..object due .to a client request, 
all connected clients must be notified so that they can 
update their displays. Another example of events is 
when a player plays ail of the audio which it has been 
requested to play. The client (s) must be notified of 
this fact so that it can update displays to indicate' 
that the audio has completed playing. Again, events are 
used for this purpose. 

When TCP/IP is used for communications between 
client and server, events are implemented as a second 



TCP connection, when the cii^n* 

" ^«es a CO. .reguest ^ ~ — 
server returns a special *~ ^ The 

identifies the client s C ° nneCti ° n hand ^" which 
°n=e the server c On ; e U 0n T C e r b V ith ^ 

- sues an ra reguest : h - :/- b 1 l r h r e ' the ciient 

associate a second TCP connection vitt the f " 
connection. The connection 

to the coif request is used retu ™ed « response 

between the client connect « ^ aSSO<=iati ° n 

Once the event connection Ts estab^T C ° nneCti °"- 
dent's responsibility ' to "It T ^ " ^ 
information. For the Dftx " for Zoning 

is used to wait for » " created which . 

received at the event ZJ^.T^- ~ 
the same format: COnnectl °"- The messages all have 

Format: Repor t an event to a client. 
Called: m <id>{< S ource> H < argunent>} 
<id> Event identifier Thi = ■ 

which identifies the event %£ 3 dec i»al number 
by the server are documented in h * 6Vents generated 
■Bvent Definitions . ocumente <S « the section titled 

<source> The source of i-k= 

indication of the . source of JZ™' This is an 
sense only in the context of ^ Vent -. " Bake s 
optional because it is boss i hi- <id> and is 

implicit in the <if> ? F * that tne source is 
indicating that the server i a ^J^ amp J^' an eve "t 
source. other events mav h»„ 9 9 dOWn " needs "o 
"Player has stopped" /„ h *u? a scurc e such as 
would be -the name-of -the-piayer * he " source 

« rarS^'t thia » a * - ~ 
arguments augment the iSf SSSto^cSSJSi in ST 

Cedents: ^client does^ £ : _ _ 

. Instead, the cS win . e Y ent channll. 

actions appropriate to the |ve"nt y perfor » in * 



PLAY LIST DESIGN 
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At the heart of the DAX audio play .hack is the 
"Play list". The play list is used to; describe a 
sequence of audio cuts (carts) which have relationships 
between each other and are to be played based on various 
events. A play list is, essentially, a program which 
the DAX players interpret to produce the required audio. 

On the disk, a play list is represented by a . 
directory with the "PLS" extend. i n the directory is a 
file which is always named with the same name as the 
directory but has the extension "TXT" . This is an ASCII 
representation of the play list. Also in the directory 
are. the cart files which make up the audio components of 
tfce play list. Normally the . carts which represent the 
playlist are .located in the play list directory, but it 
15 is possible for a play list to reference carts which are 

located elsewhere. 

The textual representation of the play list 
consists of a number of records as described in the next 
section. 

20. PLAY LIST RECORDS 

The play list is a sequence of records. All blank 
lines and lines beginning with the "*" character are 
ignored and may be used as comments. Each record begins 
-erith a keyword which identifies. the record. The keyword 
25 is followed by zero or more fields separated by one or 
more blanks. The following records make up a play list: 
-Record: REM- <remark>- - ' . - 

<remark> String which contains a remark about eh 
play list. 

30 Function: Remarks are provided to the user when the play 

list is displayed. The position of the remark 
within the playlist is used to determine where 
. the remark is displayed. Remarks outside 
. tracks are displayed at the highest level 

J3 while remarks within tracks are displayed at 

the highest level while remarks within tracks 
are displayed only when the track is 
displayed. Remarks are not shown on the Jock 
Box. 



Record: ONAIR <remark> 

Function: On air remarks are the „„„ 

they are shown on the Jort Bo " CeBarks bu * 
Record: TRACK <title> 

<title> Title associated with «. 

i22* y . . s =™«thing like J^? £»* ' This is 

imaginative as required. fe can be as 

Function: Marks the start of a groun ar 

constitute a track. LJt"!^** Which 

automatically calculates thl ^, * he s y st ea 
track. ' s 1:116 Play time-for the 

Record: EKDTRACK 

Function: Marks the end of a track. 

*««d: CART <type><title><start><si g „al><f adeout> . 

options' aref" ^ " to »° Parted. The 

^tto^p^^-f- «ith.r by a Joc k 
input. P ° r by the start optical 

- P^us^cart" " Startea at the end of the " 

^' S "»a T r\\ C nhi S efd ar oV t l>, by the <>" vi °- 
and the staVt* "of 

2 " rt ^ S e S nd ar o t f ed t he y «». 
and the start «W^^T 

"signal relay". Valid v^L / pulsa on the 
field are: 1 values for the <signal> 
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NONE No signal is generated for the cart.'. 

END Generate a signal at the end of the cart. 

MARK1 - Generate a signal at the mark 1 
location. 

MARK2 - Generate a signal . at the mark 2 
.location. 

<fadeout> Number of the fade pattern to use at the 
end of the cart. The fade, patterns are to be 
determined. 

Function: This record defines an element of audio- and 
determines how the audio is to be played in 
the show. - 

Record: BREAK <time> 

<time> Duration of local break. Specified as 
KM:SS. 

Function: This record indicates a local break in the 
•show. It causes the "start local break" relay 
to activate. Audio pauses at this point until 
the "start" relay is operated or until a start 
button is pressed on the Jock Box. 

Record: END 

Function: End of play list. 



RELAY AND OPTO-INPDT DEFINITIONS 

The affiliate may. have 4 relay outputs and 4 opto 

25 inputs per DAC card. Each card defines the relays ' as 

V_ follows : - - 

Relay outputs 

1. Play tally This relay is closed whenever the 
DAX is playing audio. 

30 2. Start local break This relay is normally 

opened and pulses closed to indicate the start 
of a local break. 

3, Signal output This relay is normally opened 
and pulses closed to indicate a signal from a 

35 cart (see CART record <signal> definition) . 

4. Onassigned 
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Optical Inputs 

l " "rf p & g . A Pttl -"^« next Banual 

2 ; -2s: -A^^r^ 
3 - s^ss^^^sr^; ■•—-> 



JOCK BOX 



The jock box is a physical >-*~ 
=*rt lo =ated i„ a "/""Nation of . DAC 

A number of audio eleLt7=a n L " 

in »uch the s aae «a y that a n^J " jOCk 

«» be placed in . I * ° f audio dements 

- ther s i P1 : d C ai ;„ rr^r; ei — — 

have an . -internal structL the „ ^ UStS 

— enable, ^ ^ .^J^ ^ * ■ ^ ksy 
Pressing the node key causes " "\ 0 " the dls P lav - 
™»re of the tr es = 3 ° ClC bC * t0 d "play 

causes t he S'JT"^ °< ^ -* *Y 

2 ' ^-^ a ^^^^ dli i, ;addition ,. 

3 " . t^c, s eVel 2 ' bUt neater detail .bout the 

At any .given time one of t h* 

displayed tree is hi ghUg hted. Lu ent " T^.T 

the current entry. if . udirt • Y aid to be 

^rrent entry inL I " " 0t Playing ' then the 

nt entry indicator may be moved by pressing 

Playing, the , ock bo)£ locks ^ ^ ^ ^ 
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stop, The foil oving table outlines >h a u 
•«-=t in different .. l"T their 



10 



*25 




DAX TRANSFER AGENT 

-t^T^L; ~^«"ons B6 = hanians , ^ 

-sentially ^ e s lnf ™°n . vill regain 

Ai y wie same. Thp K Qa j ^ _ 

connection to th. end est ^lishes 

Tuion to the remote. In a LAN version • • 

socket connect. The helT enl "" ' 

co^and to introduce the file Tu * " FIL " 

or acre "atr- J! „ **** end sends ««« 

«soci lllZl Z' t .r tribUtSS 8 " " d " a " 1— 

"DTA" , ThS head end sends 1 or no « 

s nL ;™ to — head 

tran Ier ""^ T" — the f ile 

'^-e=tsM„W T " artS ^ ^ fUe « 
t iae the transf L ""^ °' ^ UWt • " any 

abort me t " nsf """^ by the "ABT" 

EUe transfer command. 

«*HSPl» AGENT COMMAND SET 

,eaa Z TLZLIT*? ~ -VitH tne 

. . ._ a . * s _ ? a Aled. the. transfer- agent- Th"e — 
interprets the = oanands uhich 9 are J^llll 

tT^T end - The COBaanis * " s <>- d * *> 

called: COM <blocksize> 

Returns: ERR or AOK 



5 



Comments : 



Called: FIL <title><type>[<collection>] 
<title> English title for the audio. 
<type> Type of audio, (e.g., ax t of audio, p lay 

10 IVe^t?™ tPI ° f \ coUect ion that this audio 

f !e!d r Is° set to °' * COlle «"" • then this 

Returns: AOK or ERR 

is' Co1 ™^ Si%ff^ ^ t0 indicat * ^e start of 

5^1 h ile ^ rans ^ssion. Note that the <title> 
id«2i*£ an fc* anything wh . ch uni 
identifies the file, it does not necessarily 
have to be the file name in the DMS . JuShir^ 

20 Si™ <.. can „ be clumped together in 

«?li ec V°- nS - The < col ^tion> field is an 
^f? string which uniquely identifies the 
collection. The idea is that collections will 
be used to implement, "shows" or, perhaps 
libraries of audio. ^ ' 

25 Called: ATR <keylxvaluel> ... <keyn><valuen> 

<keyn> Keyword which identifies the attribute. 
<valuen> The value of the attribute. All values^ 
tf\l llV^t d i n ASCI1 s ^ings. So, for example? 

bJtf t? S 1 tring 100 not as a si "gl e binary 
th^'-v, ^ ValUe ha i embedded space characters, 
then the value is enclosed in quotation marks. 

Returns: AOK or ERR 

35 Co ™^s: Files may have attribute information which is 

used to describe the file.. One or more ATR 
commands may be sent after the FIL command. 
There can be several attribute keyword pairs 
in the ATR command. The limit is yet to be 
determined. ■ 



Called: 



DTA <data> 



audi« > fH 1 ? at \ byteS - as a PP«Priate to the fixe (e a 
weU Hit 5 hSVe SUdi ° bytes while t««t files 



well., text 
Returns: AOK or ERR 



Comments: The dat a in the file , can be either text or 

skis- as isisws i-s 



Called: END 
Returns: AOK or ERR 

counts: Marks the end of the current file's 
transmission. The file named by the previous 

suc-cesf/unr MA COmMndS h " ^ 

Called: ABT 
Returns: AOK or ERR 

Comments: Aborts the current file transfer. All 
information sent to this point is discarded by 
the transfer agent. J 

AFFILIATE/DSP PROTOCOL 

There are (conceptually) "N" units in the DSP which 
*an be controlled by the affiliate controller. All' 
-communications must take place across . the affiliate 
controller/DSP interface. Logically the "units" are DSP 
functions which ..can „be .accessed by -the - affiliate 
controller. These units accept messages f rom " the 
affiliate controller and produce message which are sent 
to the affiliate controller. One example of a unit is 
a Decoder-o, another is Decoder -1 while yet another is 
the incoming Satellite data. The affiliate controller 
sends messages to a given unit to control the operation 
of that unit. The VxD driver in the affiliate 
controller essentially "reflects" the DSP's units into 
the affiliate controller and given processes in the 



affiliate controller access to these units. The 

rotocol is designed to nove arbitrarv seguences ^ 
bytes between the affil iate controUer « 
There are several assumptions which have aade regard!™ 
the hardware use, to . i» pleBent the protocol _ "* a ^ 
These assumptions are: 

the DSP actually consists o% C ° t w troUer and 
Paths. The affiliate contra ? ° se P a «te 
to the DSP at the same ??i 3v ler oan se "d data 
data to the^u^e* con^Uer" iS ■ tmnU *. 

controller wishes to ^ " the af filiate 
. the a ssunp t^ \s |Sat a it eSSaget0theDSP 
immediately. The affili., "1 acce Pt it 
linger in the Lt w""^ 11 " wil1 

contrluer ^ ° ^Yf'ffliale 

^liir- &~ s F e r f h o4'i 

periods of time 7va-r i m-i # ■ long 
above) . variation of assumption #2 

^ * Af -filiate . . .Control 7-pr/ncn . 

■channel is error • ^ er f S r UniCati0ilS 

Sror Tree"" 1 "" ^ H 
Each message sent fro» the affiliate controller to the 
DSP and from the DSP to the affiliate controller contain 
tne same 3 basic parts: 

1. Unit number This is the number of the 
"destination" for the message. The exS 
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controller, for example, a unit is a C++ 
object which controls communication for one or 
more of the affiliate controller threads. i n 
. the DSP a unit becomes a reference to a given 

5 buffer or function in the DSP. The unit 

number may be the "address" for the message. ' 

2. Length This is the number of bytes which make 
up the message. - ■ -- 

■ 3 - , J>ata This is the actual content of the 

1° message. 

At both the affiliate controller and the DSP side 
of the link there are 2 primitive operations which are 
used to manage messages: Read and Write. All, of the 
communications logic is contained in these 2 routines 

15 for both the affiliate controller and the DSP. The 

current operation. of the read and write routines is to 
transmit data without the use of DMA. Optionally, 
sophisticated routines can be written which . select, to 
use DMA or not depending- on the size of the message 

20 buffers being transmitted. 

DAC Class 

The VxD driver must support several different DAC 
cards. For this reason, a Dac class is defined. When 
the VxD driver loads is should consult the SYSTEM. INI 
25 file (registry?) to determine how many instances of the 

DAC card should be created and what the IRQ (and later, 
DMA) assignments are.' An outline of the DAC class is: 
class Dac < 

public": ~ "~ ~" " . ■ ' ' ". 

30 Dac(int irgNum, int Dma) ; 

virtual -Dac() ; 

BOOL Ioctl (DWORD Code , LPVOID In , DWORD 
InLen, LPVOID Out, 

(DWORD OutLen, LPDWORD Result); 
35 void Hardwarelnterrupt () ; // process 

interrupts 

void LockChannel (void) ; // interface to 

g e t c a r d 
channel 

40 void Disablelnterrupt (void); // release the 

card's channel 
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45 



void Disablelnterrupt (void); / , ■ 

interrupt f or 
5 void Enablelnterrupt (void) • ?^ IRQ 

* ia > ' / /enable 
interrupt for 
mt GetDSPDataf) ; DSPIrq 

. // returns dsp 

vo id PutDSPData (intvalue); ■ 

int DSPDataPresent(void); -*** utbm - ; 

data 

private: 

15 ? n i^ *Units [MAX UNITS! • , / 

definitions "wits], , ; unit 

DaxSemaphore *Channei • , , 

channel access ■ controls 

CardlRQ *Irq; 

derived from VHardwarelnt 11 CardI RQ 

ThS baSic funct i°n of the Dac class lq \ ' 
the IOCTL requests t*?^ 13 to Process 

. The IOCTL handler i " P "" d tG At thi VxD . 

Passed to it TroJ^n T ^ 6X31011,65 ^ COate * 
upper . ML'": th 7 T d6termineS What * *>. The 
» Process the IOCTL v T ^ SeleCt Vh ° is ^ 

the f irst th ^' th A r 1Ue ° f 0X00 «*o« gh .oxo, select 

-rrentl^ ^ support ^ ^ ° n th « " ^ 

±x win support only 4 DAC card<M * 

selects the VxD^^ve/^: , ^ 

unpacks the argu B ent s and calls the " rlV " r 

30 the DAC class Pr ° Per instanc « <>* 

;"On W 3 2DeviceloCont ; ol „ is - s ^ « t he VXD 



BOOL ^V Xd: : o„ H32D , viceIOControl (pi0GTLpARAMs 
int i ; 

switch,! = ((P-»d 1 oc.l0CtlC0d.»a4,.4 OXFF), 



case OxFF 

// process the control w 
40 case 0x00: " iroi code here 

case 0x01 
case 0x02 
case 0x03 



if (Cards[i] = NULL) ( 
BadErrorOf Somesort f) * 
return (BadReturn) ; 



} 

else { > 

return Cards [ i) . loctl (p->proper 
arguments) ; 

5 . } 

} 

} ' 
This scheme lets the Dac class figure out what the IOCTL 
codes mean, with respect to. messages being send, on the 

10 individual units it owns, other member functions of the 

Dac are straight forward with the exception of 
"Hardwarelnterrupt." The problem is that the VxD gets 
the interrupt from the DSP. This needs to be associated 
with an instance of a Dac class. This is done by doing 

■15 this: 

class CardlRQ : public VHardwarelnt 
{ 

public: 

■ CardIRQ(int Inum, Dac *0wner): 

20 VHardwarelnt (Inum, 0 , 0 , 0 ) < 

void ONHardwarelnt (VMHANDLE) ; 

private: 

Dac *MyCard; // card who owns 

ZD interrupt 
. }; 

When the Dac instance is built it initializes its 
Irq member function with the statement 
Irq = new CardlRQ (IrqNum, this); 

30 Now , when there is an interrupt, the handler for 

: _ l. th . e _ specif ied_IRQ_ is .called. _ This handler -has- as its- 
private "MyCard" member variable a pointer to the, Dac 
instance that the interrupt belongs to. All the handler 
does is: 

35 CardlRQ:: On Hardwarelnt (VMHANDLE hVM) 

MyCard->HardwareInterrupt () ; 

' } 

This causes the proper hardware interrupt- routine 
40 to be invoked for the correct instance of the Dac class. 

Key to the operation of the PC protocol (written in C++ 



15 



15 the definition of «,„'„• 

^ti Cipated that dif fer e nt " ^ « is 

«• are sp b ; i t 11 wi h ; 1 ve al la ^ — w of 

«hi=h are dependent on the + * Actions 

«~ ** e Xanple ,°: h :rt:r P r re inforaation — 

«f creation it needs to toxt* it " "tellit. 

Presses r equest the intor J~ ^ 3 

input optica! isolators ho State ° f 

^"eted but siaply stor t e 7 S ' .need not be 

=l«se S fron the B y deriving different 

functionalities can be easuTac ' ^ 

^ =Xass initiau.es vU Y^n^*"*' ^ 
CreatES a " or the instances of th " n8tru * t °* " 
"ores the„ in its Units ^ °' class and 

=!»■• is deleted it walks LlkeW1Se ' whe « the Dac 

^-etes each of its M Zs ^T ^ ^ ™ 

follows: The Unit c ^ss appears as 



20 



25 



30 



35 



class unit { 
public: 

«njt (int^dr Dac *ow ner) , 

virtual - Unit( ; 
driver unload tiae 



// 



address of 
needed at 



Se); 1 ^ W ^^(char W; 
virtual int Lock (void) ; 
Vlrtual lnt Int«rrupt.tioid)..; - 



int len, 



int 
int 



Private: 

DaxSemaphore *ReadSema • 
semaphore ' 

•s^f!? aphore *UnitSema; 
semaphore ' 

Dac *Card; 

on 

char *Data; 
_ waiting buffers 



I / read 
/ / unit 
/ / the card I'm . 
//. list of 



fUnCti ° nS ° f the V «^ us parts are as follows: 



Unit - Creates an instance of the class The 
arguments are the "unit number" which will be used 
on all messages sent to the DSP from the PC and the 
instance of the Dac class which "owns" this unit 
This instance is used to gain exclusive access to 
the card's channel by this unit instance. 

-Unit - Clean up routine. The VxD will be 
dynamically loadable so when it unloads, routine 
will clean up the resources used by the unit. 

JJS?S "'Sf? ds - a » e . ssa 9 e . fr °™ the corresponding DSP 
unit This function will block the calling thread 
until a message is available. Further if a 
message is received . when there is no ' thread 
waiting, then the message will be buffeted, stored 
or discarded depending on. the definition of the 
particular unit. 

Write - Writes a message to the corresponding DSP 
unit. 

Lock - Permits a given thread to lock a unit so' 
that it can perform paired write/read operations 
without a second thread intervening. 

Unlock - Allows the thread to give up the unit. 

Flush - Discards any messages received and buffeted 
for the unit. 

Interrupt - Customized interrupt function for the 
unit. This function permits unit specific code to 
be executed at interrupt time. 

■ ReadSema - Semaphore which is used to control the 
thread's waiting for input from the DSP's, 
corresponding unit. 

UnitSema - Semaphore which is used to control unit 
locking.- - ■ . - — - - - . _ 

Note that the class DaxSemaphore is a "wrapper" 
around the "real VxD" semaphore which provides some 
additional features which VSemaphore does not provide. 
One of the most important features it provides is a way 
to release waiting tasks when the DaxSemaphore object is 
deleted. This will permit (an attempt at) an orderly 
shutdown even when tasks are waiting on semaphores. The 
Write function causes thread to wait for access to the 
DSP and once that is gained, to write the message to the 



<*sp and release the DSP . Note . . 

«ea to nake sure that the v7ite opera ? T Sh ° Uld 

"stuc,. in the output loop Not e th °" S 

<aU While writing to it J d JZZJZZ?."" C ° Uld 

"P which wouid cause the th h ' ^ 

driver. It would be nice to f "° th « 

out o f the write ioop 7^^^^ 
DSP?) n V or times we wait for 

int Unit:: Wr ite(c„ar *b Uf , int len , int ^ 

Card->LockChannel ( ) ; - , , 

OutputToDSP(unit#, ien) • Wait for Dsp 

// tell dsp 

HostVector (NEW MESSAGE) • ?? it ' . ten 9th 

~ ' ' ft interrupt 

vhile(DspReadyf) && . DSP 
MoreToSend ( ) ) OutputToDSP 
(next byte of bufT- . ^ 

data } ' 11 sen<a message 

Card->unlockchannel(} ; ;/ _ . 

; return (Someindication) ; // release DSP 

Routine which . blocks on . the unit's .'read" 
= ^ ±dea ^ t ^ : re d 

the unT em :: ted for each ,,buffern that iS 

of th^ t / bUffSrS thrSaded off 

of the "Data" member of the unit. 

int Unitxwritefchar *buf, int len, int Time, 
ReadSema->Wait() • 

buffer to be on list 11 Wait for 

InterruptOf f {) ; , , 

_ \ ft s e _e 

UnthreadBuffer (Data* • *° llow ing note 
from list t° ata ), // remove buffer 

Interruptonf) ; 

Copy(buf, DataBuff er) • ' 
ReleaseBuffer(DataBuffer) * User 
^ return (Someindication); 

-sever^^^ 

criticarrtfion^the^ 0 " th * Unit *°™ 
insures tha't k^iJ^^W.SEiS ^e 



interrupt service routine. It could be possible to 
achieve this same result by simply masking the DSP 
interrupt. This would leave all other interrupts 
on (a good thing), but 

2 . Turning off interrupt insures that another 
thread won't enter this read routine and get ahead 
of this thread. The case ;might go like this: 
there are two buffers on the list. Instead of 
turning off the interrupt system (CLI) we just mask 
the IRQ. when we pass the. semaphore . check we get 
an end of quantum interrupt and another thread 
runs. That thread also calls read, it then passes 
the semaphore and then gets the buffer we have half 
gotten in the first thread. The buffer queue is 
then messed up because both threads think they have 
the buffer {try finding that one late at night...) 

The lock routine just insures that the thread holds 

the unit. Note that the thread will be getting the 

unit's semaphore and the DSP's semaphore. There is a 

chance for a deadlock here.. To protect against - it 

perform the Lock/Unlock . sequence like this: 

. Lock(); // hold the 

unit. 

Read/write Requests () ; / / t h"i s 

locks/unlocks DSP 

Unlock(); // unlock the 

unit. 

This sequence Lock unit, lock dsp, unlock dsp 
unlock unit insures that, there will be no deadlocks. 

int. Unit: : Lock (void) 
{ 

UnitSema->Wait () ; 

> 

int Unit: : Unlock () 
{ 

UnitSema->signal ( ) ; 

} 

This is the interrupt routine. The assumption here is 
that it is: 

1. Permissible to turn the interrupt system on 
while in the interrupt handler as long as we have 
..taken precautions to insure the DSP does not cause 
us to enter the ISV a second time and... 



2. The semaphore "sianal" r ™H.. <• 
callable at interrupt time. routina 13 ' ln 

If « above is not true, then the following code 

1 T: t0 " be ^ 8 9l ° bal 6Vent »»*~ «* ^ e „ 
called fro» the event. This is *ade slightly more 
complex by the fact that toe code is a ^ ,* 

the global event's handler (this would be. done by 
define, a subclass of the ^ ^ [ 

Place « the constructor for the u„ it pointer and ^ 
storing the pointer in a private variable in the derived 
handler function - got that?,. The f oUowing^code is 
Part of the Da= =l ass and is called ^ a — 
interrupt is- received for the given card. See the 
section -Dae class" for how this all happens, this code 
is called at interrupt time and does the following: 

1. It disables further interrupts from the DSP 
DSP " if E ^ S \k See - if is a »«sag e from the 

' ?ro» I£ th? e 0 r S | UndeTo^^ii^^^^V^I^ 

that unit's interrupt function. ltcaUs 

int Dac: :Hardvarelnterrupt(void) 

Disablelnterruptf) ; // card can't re-interrupt 

interruptono ; // so OK to enable system ints 

r-eliller?- 6 - * aessa ^- fro- -the DSP (data in 

while (DSPDataPresent() ) { 

0 nitsM-^u P a []; '/,*£ ^t?r\n^r— 

routine 

Nov we attempt to receive another message from the - 



// 

// 
// 



No more DSP messages so we re-enable the interrupt 
EnablelnterruptC); // enable interrupt on card 
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DoEOIThing () ; 
} 

This is the "default" interrupt processor for the 
unit class. Note that it is called with the "length" 
5 word still in the DSP. Its job is to: 

1. Allocate a place to put the data from the DSP. 

2. Copy the date into the buffer. 

3. Thread the buffer on the unit's buffer queue. 

4 * Signal waiting threads that the buffer is 
10 there by dinging the semaphore. 

int Unit: : Interrupt () - r — 

{ ' 
len a Card->Get DSPData () ; 
AllocateBuf f er (len) ; 
15 while (len — ) 

Bufferfi] = Card->GetDSPData ( ) ; 

InterruptOff () ; . // protect while threading 

ThreadBuffer (Data,. Buffer) ; 
InterruptOn ( ) ; 

20 ReadSema->signal() ; // indicate data present 

return (Somelndication) ; 

> . / ' 

DSP Protocol 

This section discusses the implementation of the 
25 protocol for the DSP. The design is presented in C-like 

pseudo code. In the DSP units are actually data 
structures which represent linked lists of buffers. The 
DSP maintains different types of buffers for different 
. . .units. -For example,- the decoder unit maintains- buff ers 

30 which are large enough to hold a specified number of 
MUSICAM frames. Each buffer looks like this: 
struct . buf { 

struct buf *Next; // pointer to next buffer 
- on list 

35 i nt Done; // buffer has been sent ■ 

int UnitNumber; // destination unit number 

int Len; // length of data portion 

char Data[??]; // data in buffer 

>; 

4 0 There are several key routines in the DSP. These are 
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Se^; takes a buf £ « and init *"~ 

^" Int 'This is the interrupt half of the write 

Readlnt - This is the interrupt half of the read pc 
routine, it is called via interrupt each ti»J <-*f 
PC writes into the DSP ' s data port the 

PCInt - This routine is called to generate a PC 
interrupt and to disable the PC interrupt? A kev 
.,. assumption is as follows: if the PC has th« S 

15 chip masked (interrupt disabled for a DSP IRo! Ind 

StL^^n' 1 " 16 the PIC chip is unmasked, the 
interrupt will occur. 

An additional assumption is that the interrupts 
20 generated when the PC inserts, a word into the DSP's data 

buffer can be disabled. Further interrupts generated 
when the PC removes a word from the DSP's data buffer 
can also be disabled. 
WritePc 

25 The WritePC and the Writelnt routines work together. 

The pseudo code for the routines is as follows: 

Transf erlnProgress = FALSE; 
struct buf *SendList = 0; 

The WritePC routine is used to send a message to 
30 - , t he PC; - Messages are" queued' in thVsendList as they are" 
received. 

WritePC (Buffer) { 

Disablelnterrupts ( ) ; 
Thread' Buf fer to end of sendLisf 
J3 Enablelnterrupts ( ) ; 

if {not Transf erlnProgress) { 
Transf erlnProgress ; 
Fill DspToPC output register; 
An Enable (Writelnterrupts) ; 

*° PCInt (ON) ; 

)''.'- 



The Writeint routine is callo , 

*«- th. DSP - S output buffer " 8 W ° rd iS take " 



Writeint ( ) 
{ 



if (no nore bytes in buffer ) t 
Disablemterruptsn J { 
Mark buffer done • U ' 
xf (More buffers on. queue) < 

PCInt ° UtPUt «»i-t-r; 
{ 

TransferlnProgress J>£i E . 



} 

else { 



} 

} 



' else if {fi rs t byte) / 
PCInt (OFF); X 
y ° UtpUt byte i n buffer; 

else { 

} output. next byte i n buff er; , 



Readpc 



the DSP a ..unif is actual 9 ly a *™' I* the ""text of 
■«ith the sarae unit number When th / * "" M " 9 " 

-essage to the DSP lt PC W " tS to - 

interrupt Thi = 1SSUeS 3 NEW -"ESSAGE host 

^euea on the ^.t.^ ****** is 

by the nast er routine M l ^ ^ 
Processed by it This Bro „ * the ""sages are 

he generate,. J^ r Z£?"* "* «-P«~ - 

routine. responses are sent via the WritePC 



ReadPC ( ) 



Read the unit number; 
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Read the length; 
Allocate appropriate buffer- 
■ Enable (Readlnterrupts) ; ' 

5 Messages 

This section discusser <-h 

------- ospaTL" 7 e r s which a - 

two general categories: - Messages fall intQ 

message, response message ln P ai "= request 

are only sent to . -^/rj^^-i^ 

. r«po^r^^-" -«*" «« -nt ana no 

. uses' the comaunications 1 T "° 0ther th " ad 

»« w aiting for . :::x::: s z?z whiie the thread i - 

routines in order to insure ^ 'UnlockO 
responses are „ messages and their 

ponses are sequenced properly wh— 
. generated for a request tHe response is 

25 message number as iiTT' ^ the sane 

responds with READ OPTXCAL is L s ^ ^ 

.Unit Assignments ~ ~* " 9 ' " Umber - 

the implementation, however untts , , T ° Si » Plif * 

■ three di fferent wa ; s 7 er ' ^ WU1 b ^tilized 

trans*!? ^s^Vr^' ^ ^ used to 

example of a reld only uni^ is^n VL th<? Pc - A " 
unit. The DSP writes satelilt^ Sat ellite data" 
when it is received f f "m^nt - ■ to this unit 

transm^^rstges^^Vlo^"." 6 used '*» 
never ^ £ ■» 
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An_ example of this type of unit is the "control" 

J; a „i?l te - /J ? ad I"? esa types of units are used to 
transmit information from the PC to the DSP and to 
receive information back from the DSP. The "rad 
°^i Cal w lnput . s J' unit is a " example of this type of 
S J;. n« W1 - te /f ead Units the pc vrites * message 
. Dsp'tl re%o a n n d d th£n ^ *° bl ° C * S Waitin * <~ ^ 

Knowing the type of unit (read only, write only or 

write read) permits derived classes used to. implement 

the unit to perform error checking to insure that the 

unit is properly called from system code (e.g. the read 

routine of a write only unit can trap an error) . The 

following units are defined- for the DAX protocol. Note 

that the designations "read and write" are relative to 

the PC's perspective (i.e. read only means the PC will 

only read from the unit) . : 

, n Control - [Unit #0, write only] The control unit is 

used to send all messages from the PC to the DSP 
which do not require 'any responses. 

Event - [Unit #1, read only] Event messages from 
the DSP to the PC are written to the Event unit. 
The PC reads this unit to wait for event messages. 

25 Ancillary Data - [Unit #2, read only] Any ancillary 

data from the decoders is written to this unit. 

Sat Data - [Unit #3, read only] Received satellite 
information (MUSICAM records and command records) 
is read from this unit. 

30 Optical inputs - [Unit_#4, write/read] The PC can 

request the state of " the card's optical Inputs and 
read the response from this unit. 

Decoder State - [Unit #5, write/read] The PC can 
_, request the state of the card's decoders and read 

J:> the response from this unit. 



Request Audio - [Unit #6, read only] The DSP sends 
requests to the PC to get it more audio over this 
unit. 



The rational for unit assignment is as follows: 
ii " SI "control d0 u e nit" 0t S£ 

own "nit ""Sit T dS 3 res P° nse "sign it to its 

PC To DAC Massages 

This section contains an of the. messages which are- 
sent from the PC to the DAC. it provides ' unit 
assignments for each message. Optionally, the bytes may 

be sent in one of two ways. 

' 1. 'Pack the bytes as tightly as possible ' This 
optx^zes the number of interrupts £££ the Dsl 
20 " roS ?° nd IS" ° rdSr t0 trans f« the bytes, but 

receives ° SP t0 Unpack the ^es it. 

L ,f S ^^ aii i^^ent* regardless of original size 
sldLt 1 *^ 3 ' J^ iS makes *»» DSP unpacking job 
25 sianlff; a ^ U i v UP ? the Z""*" 1 " of bvtes transferred 

5 y * Lar< * est nu ^r of bytes are sent as . 
^ese^iii^" or ^ eceived satellite information. 
wSrds. sent as completely packed 24 byte 

In order to delay the decision of how data is sent, 
30 a "message class- will be defined which provides the 

following "services 1 - - - - 

class Message {• 
public: 

35 Void Start(int Mnum); // begins assembling a 

message 

void .Put (int) ; . // puts an integer 
void Put(char); // puts a byte 

™J"2 S U 5l Sh ?? ,; 11 pUts a 16 bit integer. 

40 E^(void); // ends the message 

* u : void SendBuffer y 

(Dae *Card); .// sen d the message out 



The Message class encapsulates the format . of the 
actual message, it is called from higher level routines 
and is used to construct a message buffer. The buffer 
is then sent to the. card. Given all of this, however, 
each message must have a message number to uniquely 
identify it, the length of the data and arguments. 
Set satellite da ta selection switch) 
unit: Control; Unit #o 

Arguments: Switch position code. (i byte) 
Response: None 

Comments: The positions of the switch are shown in the 
following table: 



Switch Pos Code 


Satellite data passed to 


0 


Nothing (satellite input is ignored 


1 


Decoder 0 only 


2 


Decoder 1 only 


4 


PC only 


5 


PC and decoder 0 


6 


PC and decoder 1 



Note that only these values are available. 
Any. other value for the switch position is 
invalid. 

Set sta tion addrpgc 

Unit: Control, Unit #0 

Arguments: Station address value. (2 bytes) 
Response T None " ~ 

Comments: The' 16 bit argument is used as the- station 
address 



Add st ation to a group. 
Unit: Control, Unit #0 

Arguments: Group number to add station to. 
Response: None 



(2 bytes) 
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25 



Comments: Adds the station to <-h* 

There can be a maximum ofS!?*?^?** * rou P' 
in the system. After even, 1 \ tlnct groups 
. card is not a member of an ?^ UP ' the D * c 

s pecifi6d ^ ^e^^ 
Pemove H ^atin p f , on a 
Dl »": Control, Unit to . 

ssr*"* Group nuBber station Iron . (2 

Response: None 

Coaments: Removes the stain * -' 

Only the low order 9^^? X"*"** group. ' 
used to determine the . argument are 
station is not a member UP of nU ?? er " ■ If - the 
group, the call is ignored. specified... 

Read npi- < cal ,ip r „ fc 

D =it: Optical inputs, unit # 4 

Arguments: No arguments 

response: Value of «^ optical ^ ^ ^ 

events: This reads ; ^ ^ ^ ^ ^ 

• Control relay 

control, Unit #o 

■SiBBlFfi-ths operatiin b i^ iS f elay number" (0-3) "lower 
(1 byte) . °P era tion taken from the following tab^ef 

Duration of pulse in we « 
set-to o. (2 bytes) ' ' If not P ulse operation . 
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p i Lover Byte 



Relay operation selected 



0 



Open the relay and leave open 



1 



Close the relay and keep closed 



2 



Open relay for PpMS and then cl> 



5 



3 



Close relay for P,MS and then Open 



Response: None 



Comments : 



Load segment infn™**,^ 



Unit; 



Control, Unit #0 



10 




following arguments are presented in 
i message 



1. Segment id. This is a unique number which the 
DSP can use to identify the segment'. (2 bytes) 

2. Decoder; Which decoder to load this segment 
to. This may be either 0 or l. (l byte) 

3. Start facie: Number of the fade pattern to be 
used when starting the segment's play back. A 
pattern number of 0 means, don't fade. (l byte) 

4. 2nd Fade: Number of the fade pattern to be 
used with ending the segment's play back. A 
pattern number of 0 means don't fade. {l byte) 

5. Marker i position. Location of marker 1 in 
■frames from the start of the segment. Note that 
the position cannot be beyond the end of the. 
segment. A value of 0 means there is no marker 1 
(3 bytes) 

6. -Marker 2 position: Same definition as marker 
1. (3 bytes) 

7. start opinion: The even which starts the 
segment playing. The value can be taken from the 
following, (l byte) 

0: Start command from the PC. 
1: End of previous segment in this channel 
2: End. of most recently loaded segment in the 
, other channel 
3: Marker #1 of most recently - loaded segment 
in the other channel . 



In thfo e the # r ohan^l. """^ ' loUM 

L e /'?." t f i f^ a: . Generates an event to the PC 
v^ues cfn f £ U ° Wi 1? condit ""s. Note that the 
even?? .(TbyS, =°» blned to ^nerate acre than i 

9. Number of frame time to mute Tf „„„ 
Response: None 

Comments: The DSP will generate interrupt reou«t* 

-"S^ 1 ?* data f ° r ^ back bfsed e o q n "he 
segment ID passed to it. _ 

Reset s egment play staclf - 
Unit: Control, Unit #0 

Arguments: The number of the decoder to reset: (l' byte) 

1: Decoder-0 
2 : Decoder-l 
3: both decoders. 

Response: None 

Comments: Note that if decoders are playing, then they', 
will first stop and then reset. 

Decoder pi„ y 

Unit: Control, Unit #0 

U^teT'' nUmbSr ° f ^ decoder t0 start Playing: 



1: Decoder-0 
2: Decoder-l 
3 : both . decoders . 



Response: None 
Comments : 



Stop decoder 

Unit: Control, Unit #o 



■(PSST nm " ber to stop playing 

1 : Decoder-0 
2 : Decoder-l 
3 : both decoders . 

Response: None 
Comments: 

Begin liv. w y 
u nit: Control, Unit >o 
Arguments: None 
Response: None 

COMMtS! ~^£ L &\szs? - - — 

Get riprn^er s -h Wl - 0 

Unit: Decoder state, Unit #5 

Argument: The number Qf ^ ^ 

1 : Decoder-0 
2: Decoder-l 

Response: Three values: 

topped •"Vla e ?iS' ThiS "» be ° = 

W ' l : Pla ymg. 2: Playing live, (i byte) 

or 2 (playing live) . ™ « 0 (topped) 



Unit: . Control, Unit #0 

Arguments: Decoder number (1 byte) 

0: Decoder-0 
1: Decoder-l 

2: Both decoders gain change at once. 
Gain level (2 bytes) 

Response: None 

Comments: Changes' the gain level for the specific - 
decoder. 



MUSI CAM Data 

Unit: ■ Control, Unit #0 

Arguments: Decoder number to play data on. This can 
be 0 or 1. 

Number of frames being sent (0 means no more frames 
in segment) . 

Integral number of MUSICAM formatted frames. 
Response: None 

Comments: This message is sent in response to the DSP 
"request audio data" 

OAC TO PC MESSAGES 

This section outlines the messages which the DAC 
can send to the PC. 
Regue~st ftucUo Data ' * 

Unit: Request Audio, Unit #6 

Arguments: Segment number (1 byte) 
Decoder Number (l byte) 

Maximum number of MUSICAM frames DSP can 
accept (2 bytes) 

Response: At a later time (not in strict response to the 
request i.e. the DSP does not waif for the 
response) the PC will send a MUSICAM Data 
message with the new data. . 



Comments: The DSP sends this request whenever It feels 
that it needs more MUSIC AM data. 



Satellite n»*» 

Unit: sat Data, Unit #3 

Arguments: Data from satellite. This is a sequence of 
bytes . 

Response: None 

Comments: The receiver of the satellite data understands 
the semantics of the data. The DSP has 
synchronized with the data and has recognized 
the headers enough to determine that *he data 
is addressed to the particular DAC card. The 
format of the data will be determined at a 
later date. 



Event Data 

Unit: Event, Unit #1 

Arguments: The event messages. Each message has the 
same format. There are an integral number of events 
sent in each message. 

Response: None 

Comments: The even messages are formatted as follows: 

1. The device ID (1 byte) This identifies the 
source of the event. Currently defined devices 
are: 

0 : Decoder-0 
1 : . Decoder-1 

...... . 2 :_ Optical .isolators . . _ 

2. Event ID (1 byte) This identifies the type of 
the event. Currently defined types are: 

0: End of segment. Data is the segment number 
of audio. 

1: Marker #1 played. Data is- the segment 
number of audio. • 



2: Marker #2 played, 
number of audio. 



Data is the segment 



-sa- 



lt Change in optical isolators,.. -Data is the 
current setting of the isolators. 

3- Data value (3 bytes). Content of the data 
depends on the Event. a 

Ancillary Da t^ 

Unit: Ancillary Data, Unit #2 

Arguments: The ancillary data is packetized r*n* 

EST £ 2 \^\\£>t*: which is 

1. The decoder number the data came from. 

headed nUmber ° f bytes of data following 
Response: None 
Comments : 

Read Opt ical Inrmts 

nnit: Optical inputs, Unit #4 

Arguments: Current optical input values in low order 4 - 
bits {l byte) 

. Response: None 

Comments: This message is sent by the DSP in response to 
a Read Optical inputs message from the PC. 

Get Decoder State 

Dni t_ : Decoder. State , Unit #5 

Arguments: Three values: 

1. The state of the decoder: This can be o- 
Stopped, 1: Playing, 2: playing live, (l byte) 

2. The segment number being played. A value 
of 0 is returned if the state is 0 (stopped) 
or 2 (playing live). (1 byte) 

. 3. The frame number is being played. If the 
decoder is stopped then the returned value is 
0. (3 bytes) 



Response : None 



OPERATIONAL REQUIREMENTS 

This sectiQn discusse 
functionality provided by affiliate . . 0perat i°nal 

. 4 different types of J^h ^ 

managed by the systea. * deliv «ed and 

1. Recorded shows with regional spots 
r 2 - "ve shows with regional spots " 

Delav p^y S how S .„i thregional spots ' 

4- Conmercia Is and other audio 

The Affiliate ter»inal provides ' .„«: 
Permit the recently S fe atures which 

authentication : P each ' ^T^' ^ »^ 

actions d is CUSS f th r au t t ;; e : u : n :- th - — * 

systen provides for th» features the 

•*U- types repre^S a IT 396 ";" ** ^ *«* ° f ^ 
. I- engaged in ~ i y £ JST" ^ 
and associated challeno' ° f thiS bUSiness ' 

«e* to. the ulr^IZ *" '"""^ in A PP-*« A. 
t*. of audio t" "s a ! ! Pr ° Vided C « ««* 

«* ^ piay lit ; h r c-rrirr 

following section. . * describe * i" the 

PLA * "STS AMD EVENTS 

About the onlv «™V ■ * 13 seldom don *- 

ne only application which results in «-'>,. ■ , 

Playxng of audio is „ hen . d-xlw ^" 
dubbed onto a * "Slivered commercial' is 

terminal "ui p^r' t * P " N °™ llv **• "flli.t. . 

«* • ^1 »T SM ° f aUd " Under the =°"trol 

-udio events Audio ' * 

Audxo events are sequences of audio which 



play to completion before another— audio event occurs. 
Radio is the management of audio events. For each audio 
event that are 5 properties which are of interest to a 
potential user: 

1. Class of the event (internal/external) 

2 . Start trigger . . 

3. Termination signal. 

4 . Out cue . 

5. Event duration. 

Of these the first 3 may be specified by the 

event's user while the last 2 are intrinsic properties 
associated with the given audio event. 



EVENT CLASSES 

The [MEx DAX - Affiliate] terminal provides 2 event 
classes : 

1. Internal. Internal events are those which ar 
generated within the [DAX - Affiliate] terminal 
itself. These could be, for example, a segment of 
an Casey Cassam's Top 4 0 show or a commercial 
stored in the [DAX - Affiliate] terminal. 

2. External. External events are those which are 
generated outside the [DAX - Af filiate] ■ terminal. 
These could be, for example, a commercial located 
on a cart machine , a live announcer reading the 
news at the top of the hour or a station call 
letter sounder". 



START TRIGGER 

Each event on a play list is said to have a trigger 
which causes the event to start. The ( DAX - Affiliate] 
terminal supports the following triggers: 

1. Contact closure. An event which is triggered by 
a contact closure will begin playing when the 
closure is received at the [DAX - Affiliate] 
terminal . 

2. Pseudo contact closure. This is an internal 
software signal which permits one play list to 
start another play list executing. This is used 



primarily to enable live- -audio to cut to other 
audio events stored in a play list. 

3. Previous event termination (PET) . PET event 
triggers cause an audio event to immediately follow 
its previous event. This results the flow of one 
event into another without pause or external input.. 

Having multiple events in a play list which have 
different event triggers can result in a rich 
operational feature set: For example, suppose a 
sequence of 3 commercials are to be played back to back, 
following a contact closure. This play list would be 
set. up so that audio event ! (the first commercial) is 
closure triggered while the net two events are PET 
triggered. Further, the first two events would produce 
no termination signal while the third could be selected 
to produce a contact closure termination. The result is 
that a closure starts the commercials playing , each 
commercial plays in sequence and a contact closure is 
activated to indicate completion of the commercial set. 
TERMINATION SIGNAL 

When an audio event is. done executing it may, 
optionally, generate a completion signal. There are two 
types of completion signal listed below. Either or both 
termination signal may be specified for any given audio 
event: 

1 . Contact closure . This causes a specified 
contact to, close when the audio event is completed. 

2". Pseudo contact closure . This is a sof tware 
indication which can be used to resume a stopped 
• play list. 

USER RECORDED EVENTS 

Although not slated to be initially provided in the 
MEx feature list, there is no reason why subscriber 
stations cannot record their own audio events. Given 
this capability, it would be possible to convert what 
would otherwise be external events into internal events. 
The net result would be more station automation. It 
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3. The head end syjstem...will deliver the play list. 
-The play list will sequence the segments and the 
commercials along with the local available spots. 

The following could be an example of a play list: . 

Event 1 TOP 4 0 Segment 1 

Event 2 TOP 4 0 Spot 1 

Event 3 TOP 40 Spot 2 

Event 4 Local spot 

Event 5 TOP 40 Segment 2 

.Event 6 TOP 4 0 Spot 3 

Event 7 Local spot 

Event 8 TOP 4 0 Segment 3 

The system is set up to have Event 1 trigger on a 
contact closure. This starts the show playing. Event 
2 and Event 3 are triggered on the termination of the " 
previous event. This results in smooth flow from Event 
1 to Event 2 to Event 3. Event 3 has as its termination 
signal a contact closure. This signifies the start of 
.the local spot and can be used to interface to the 
station automation system that Event 4 is to start. 
Event 5 triggers on a contact closure which indicates 
the end of the local available spot indicated by Event 
.4. . The play list along with the particular files down 
loaded into the DAX terminal are all that is required to 
produce the forzaatics sheet for the station. The 
f errmatics which the subscriber station manager can 
examine or print 'out is developed from the play list and 
the component, audio files. Not that each audio event 
has a duration-and an- out- cue- associated with it .- - This , 
permits the internal generation of the formatics for 
each show even it the regionalization results in 
different formatics {because of different outcues from 
regionalized commercials) at each station. 
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The claims defining the invention are as follows: 

1 . An improved method of transmitting at least audio information from production 
systems to one or more among a predetermined group of tail end users distal from the 
production systems, the improved method comprising the steps of: 

a. receiving at least a first audio signal on a first production system and at 
least a second audio signal on a second production system; 

b. digitally encoding the first and second audio signals with a lossy 
compression algorithm to yield respective first and second lossy encoded files of lossy 
audio information; 

c. predetermining a first group of tail end user apparatus for use of the first 
lossy encoded file and a second group of tail end user apparatus for use of the second 
lossy encoded file; 

d. transmitting the lossy encoded files from the first and second production . 
systems to a hub for automatic selective forwarding of the first and second lossy encoded 
files by the hub to the first and second groups of tail end user apparatus respectively; and 

e. receiving, decoding, and playback broadcasting of the first and second 
lossy encoded files respectively on the first and second groups of tail end user apparatus, 
said decoding using a decoding algorithm for decoding of the lossy encoded file encoded 
with the lossy encoding algorithm. 

2. An improved method of transmitting at least audio information from a 
production system to one or more among a predetermined group of tail end users distal 
from the production system, the improved method comprising the steps of: 
" ~ " £ receiving a"first audio'signal on the production system; - 

b. digitally encoding the audio signal with a lossy compression algorithm 
to yield a lossy encoded file of lossy audio information; 

c. selecting which selected tail end user apparatus among the group of tail 
end user apparatus should receive and use the lossy encoded file; 

d. for each of the selected tail end user apparatus, determining whether to 
transmit the lossy compressed digitized file through a satellite link or other link; 

e. . for each of the selected tail end user apparatus, automatically 
transmitting the lossy encoded file to the* respective selected tail end user apparatus 
through the respectively determined link; 
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f. receiving and storing the lossy encoded file on the selected tail end user 
apparatus for subsequent decoding and use of the lossy encoded file by the selected tail 
end user apparatus, said decoding using a decoding algorithm for decoding of the lossy 
encoded file encoded with the lossy encoding algorithm. 

3. An improved method of transmitting at least audio and data information from a 
production, system to one or more among a predetermined group . of tail end users distal 
from the production system, the improved method comprising the steps of: 

a. receiving a first audio signal on the production system; 

b. digitally encoding the first audio signal with a lossy compression 
algorithm to yield a first lossy encoded file of lossy audio information; 

c. producing a separate data file of non-audio information, including a 

playlist; 

d. predetermining which selected tail end user apparatus among the group 
of tail end user apparatus should receive and use the first lossy encoded file and the data 
file; 

e. automatically transmitting the first lossy encoded file and the data file 
from the production system to the predetermined tail end user apparatus through an 
extraterrestrial satellite; 

f. automatically receiving and storing the first lossy encoded file and. the 
data file on the predetermined tail end user apparatus, without further lossy compression 
of the lossy audio information in the first lossy encoded file, for subsequent decoding and 
use of the lossy encoded file, either on demand or according to the play list, said decoding 
using a decoding algorithm for decoding of the first lossy encoded file encoded with the 

i lossy encoding algorithm. 

4. An improved method of transmitting at least audio information from a 
production system to one or more among a predetermined group of tail end users distal 
from the production system, the improved method comprising the steps of: 
0 . ^ receiving a first audio signal on the production system; 

b. digitally encoding the audio signal with a lossy compression algorithm 
to yield a first lossy encoded file of lossy audio information; 

c. producing a separate data file of non-audio information including a 
playlist associated with the first lossy encoded file; 
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d. selecting which selected tail end user apparatus among the group of tail 
- end user apparatus should receive and use the" first lossy encoded file and the data file; 

e. automatically determining whether to transmit the first lossy 
compressed digitized file and the associated data file to the selected tail end user 
apparatus through a satellite link or other link; 

f. . transmitting the first lossy encoded file and the associated data file to 
the selected tail end user apparatus through the determined link; 

g. automatically receiving and storing the first lossy encoded file and the 
associated data file on the selected tail end user apparatus, for subsequent use of the data 
file and decoding and use of the lossy encoded file, said decoding using a decoding 
algorithm for decoding of the first lossy encoded file encoded with the lossy encoding 
algorithm. 

5. An improved method of transmitting, at least audio information from a 
i production system to one or more among a predetermined group of tail end users distal 
from the production system, the improved method comprising the steps of: 

a. ' receiving first and second audio signals on the production system; 

b. digitally encoding the first and second audio signals with a compression 
algorithm to yield respective first and second encoded files of audio information; 

o c. predetermining one or more tail end users from among a group of tail 

end users and generating digitally encoded instructions to the tail end user apparatus for 

■ decoding and playback of the first and second encoded files; 

d. automatically multiplexing the first and second encoded files and 
encoded playlist into a multiplexed data stream; 

u " e . " automatically" transmitting the" multiplexed data stream- to the 

predetermined tail end user apparatus through an extraterrestrial satellite; 

f. receiving the multiplexed and transmitted data stream, de-multiplexing 
the data stream, providing output including the encoded file and the encoded playlist on 
the tail end user apparatus, and decoding and using the encoded file according to the 

30 encoded instructions. 

6. The improved method of claim .1 wherein: (1) the transmission step (d) takes 
place without further lossy compression of the lossy audio information in the lossy 
encoded file; (2) the transmission step includes transmission of a live encoded audio data 
35 stream by automatic multiplexing and transmitting the audio data stream with the lossy 
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encoded file; and (3) the receiving step (e) includes automatically demultiplexing of the 
received multiplexed audio data stream and lossy encoded file, and live decoding and use 
of the audio data stream by the tail end user apparatus. 

7. The improved method of claim 2 wherein: (1) the transmission step (e) takes 
place without further lossy compression of the lossy audio information in the lossy 
encoded file; (2) the transmission step includes transmission of a live encoded audio data 
stream by automatic multiplexing and transmitting the audio data stream with the lossy 
encoded file; and (3) the receiving step (0 includes automatically demultiplexing of the 
received multiplexed audio data stream and lossy encoded file, and live decoding and use 
of the audio data stream by the tail end user apparatus. 

8. The improved method of claim 3 wherein: (1) the transmission step (e) takes 
place without further lossy compression of the lossy audio information in the lossy - 
encoded file; (2) the transmission step (e) includes transmission of a live encoded audio 
data stream by automatic multiplexing the audio data stream with the lossy encoded file 
and the data file; and (3) the receiving step (f) includes automatic demultiplexing of the 
received multiplexed audio data stream, lossy encoded file, and the data file, and live 
decoding and use of the audio data stream by the tail end user apparatus. 

9. The improved method of claim 4 wherein: (1) the transmission step (f) takes 
place without further lossy compression of the lossy audio information in the lossy 
encoded file; (2) the transmission step (f) includes transmission of a live encoded audio 
data stream by automatic multiplexing the audio data stream with the lossy encoded file 
and the data "file; and the" receiving step~(g)" includes "automatic ; demultiplexing-of the 
received multiplexed audio data stream, the lossy encoded file, and the data file, and live 
decoding and use of the audio data stream by the tail end user apparatus. 

10. The improved method of claim 5 wherein: (1) the transmission step (e) takes 
place without further lossy compression of the lossy audio information in the lossy 
encoded file; the transmission step (e) includes automatic transmission of a live encoded 
. audio data stream by multiplexing the audio data stream with the lossy encoded file; and 
(3) the receiving step (f) includes automatic demultiplexing of the received multiplexed 
audio data stream and lossy encoded file, and live decoding and use of the audio data 
s stream by the tail end user apparatus. 
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11. An improved method of transmitting at least audio information from a head end 
to one or more among a predetermined group of tail end users distal from the head end, 
the improved method comprising the steps of: 

a. receiving a first audio signal on a production system; 

b. digitally encoding the audio signal with a lossy compression algorithm 
to yield a lossy encoded file of lossy audio information; 

c. predetermining one or more tail end~users from among a group of tail 
end users; 

d. transmitting the • lossy encoded file from the head end to the 
predetermined tail end user apparatus; 

e. receiving the lossy encoded file and decoding of the lossy encoded file 
on the predetermined tail end user apparatus, said decoding using a decoding algorithm 
. for decoding of the lossy encoded file encoded with the lossy encoding algorithm; and 

f. local storage and automatic insertion of a spot segment into a playback 
generated by the predetermined tail end user apparatus. 

12. The improved method of claim 11 wherein the transmitting step (d) includes 
transmission through an extraterrestrial satellite without further lossy compression, lossy 
decompression, or editing of the lossy audio information in the lossy encoded file. 

13. The improved method of claim 12 wherein the transmitting step (d) includes 
predetermination of whether to transmit through an extraterrestrial satellite or other link 
and then transmitting through the determined link. 

14. The improved method of claim 13 wherein the digital encoding step (b) also 
includes creating a non-audio data file and bundling the data file with the lossy encoded 
file for transmission of the data file with the lossy encoded file in step (d), and for 
reception of the data file with the lossy encoded file in step (e). 

15. The improved method of claim 2 wherein the method includes a step (f): playing 
the decoded file and automatically cross-fading the playback of the decoded file with the 
playback of a second audio file on the tail end user apparatus. 
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16. The improved method of claim 3 wherein the transmission step (e) takes place 
without further lossy compression of the lossy audio information in the lossy encoded 
file, and wherein the method also includes as step (g): playing the decoded file and 
automatically cross-fading the playback of the decoded file with the playback of a second 
audio file on the tail end user apparatus. 

17. The improved method of claim 4 wherein the transmission step (e) and the 
reception and storage steps (f) take place without further lossy compression of the lossy 
audio information in the lossy encoded file, and wherein the method also includes as step 

3 (h): playing the decoded file and automatically cross-fading the playback of the decoded 
file with the playback of a second audio file on the tail end user apparatus. 

18. The improved method of claim 5 also including as step (g): playing the decoded 
file and automatically cross-fading the playback of the decoded file with the playback of a 

j second audio file on the tail end user apparatus. 

19. The improved method of claim. 6 also including as step (d): playing the decoded 
file and automatically cross-fading the playback of the decoded file with the playback of a 
second audio file on the tail end user apparatus. 

20 

20. The improved method of claim 7 also including as step (g):. playing the decoded 
file and automatically cross-fading the playback of the decoded file with the playback of a 
second audio file on the tail end user apparatus. 

23 21. The improved method of claim 8 also including as step (g): playing the decoded 
file and automatically cross-fading the playback of the decoded file with the playback of a 
second audio file on the tail end user apparatus. 

22. The improved method of claim 9 also including as step (h): playing the decoded 
30 file and automatically cross-fading the playback of the decoded file with the playback of a 

second audio . file on the tail end user apparatus. 

23. . The improved method of claim 10 also including as step (e): playing the 
decoded file and automatically cross-fading the playback of the decoded file with the 

35 playback of a second audio file on the tail end user apparatus. 
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24. The improved method of claim 11 also including as step (f): automatically, 
cross-fading the decoded file playback with the spot segment playback during the 
playback on the tail end user apparatus. 

25. The improved method of. claim 12 also including as step (f): automatically, 
cross-fading the decoded file playback with the spot segment playback during the 
playback on the tail end user apparatus. 

26. The improved method of claim 13 also including as step (f): automatically 
cross-fading the decoded file playback with the spot segment playback during the 
playback on the tail end user apparatus. 

27. The improved method of claim 14 also including as step (f): ' automatically 
cross-fading the decoded file playback with the spot segment playback during the 
playback, including playback broadcasting, on the tail end user apparatus. 

28. The improved method of claim 3 wherein: step (a) includes receiving a second 
audio signal on the production system; step (c) includes digitally encoding the second 
audio signal with the lossy compression algorithm to yield a second lossy encoded file of 
lossy audio information; step (c) includes incorporating a play list into the data file; step 
(d) includes transmitting the first and second lossy encoded files along with the data file; 
and step (f) includes receiving and storing the first and second lossy encoded files on the 
predetermined tail endapparatus and use of the encoded files according to the. instructions 
in the play list. 

29. The improved method of claim 4 wherein: step (a) includes, receiving a second 
audio signal on the production system; step (c) includes digitally encoding the second 
audio signal with the lossy compression algorithm to yield a second lossy encoded file of 

Jossy audio information; step (c) includes incorporating a play list into the data file; step 
(f) includes transmitting the first and second lossy encoded files along with the data file; 
and step (g) includes receiving and storing the first and second lossy encoded files on the 

■ predetermined tail end apparatus and use of the encoded files according to the instructions 
in the play list. - 
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30. The improved method of claim 8 wherein: step (a) includes receiving a second 
audio signal on the head end; step (c) includes digitally encoding the second audio signal 
with the lossy compression algorithm to yield a second lossy encoded file of lossy audio 
information; step (c) includes incorporating a play list into the data file; step (d) includes 
transmitting the first and second lossy encoded files along with the data file; and step (0 
includes receiving and storing the first and second lossy encoded files on the 
predetermined tail end apparatus and use of the encoded files according to the instructions 
in the play list. 

31. The improved method of claim 14 wherein: step (a) includes receiving a second 
audio signal on the production system; step (c) includes digitally encoding the second 
audio signal with the lossy compression algorithm to yield a second lossy encoded file of 
lossy audio information; step (c) includes incorporating a play list into the data file; step 
(d) includes transmitting the first and second lossy encoded files along with the data file; 
and step (f) includes receiving and storing the first and second lossy encoded files on the 
predetermined tail end apparatus and use of the encoded files according to the instructions 
in the play list. -'■ ^ 

32. The improved method of claim 1 8 wherein: step (a) includes receiving a second 
audio signal on the production system; step (c) includes digitally encoding the second 
audio signal with the lossy compression algorithm to yield a second lossy encoded file of 
lossy audio information; step (c) includes incorporating a play list into the data file; step 
(f) includes transmitting the first and second lossy encoded files along with the data file; 
and step (g) includes receiving and storing the first and second lossy encoded files on the 
predetermined tail end apparatus"and'use of the encoded files according to the instructions 
in the play list. 

33. The improved method of claim 21 wherein: step (a) includes receiving a second 
audio signal on the production system; step (c) includes digitally encoding the second 
audio signal with the lossy compression algorithm to yield a second lossy encoded file of 
lossy audio information; step (c) includes incorporating a play list into the data file; step 
(d) includes transmitting the first and second lossy encoded files along with the data file; 
and step (f) includes receiving and storing the first and second lossy encoded files on the 
predetermined tail end apparatus and use of the encoded files according to the instructions 
in the play list. 
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' 34. The improved method of claim 12 wherein: step (a) includes receiving a second 
audio signal on the production system; step (c) includes digitally encoding the second 
audio signal with the lossy compression algorithm to yield a second lossy encoded file of 

, lossy audio information; step (c) includes incorporating a play list into the data file; step 
(f) includes transmitting the first and second lossy encoded files along with the data file; 
and step (g) includes receiving and storing the first and second lossy encoded files on the 
predetermined tail end apparatus and use of the encoded files according to the instructions 
in the play list. 

o . 

35, The improved method of claim 1 wherein transmitting step (d) includes 
transmitting contact closure information in connection with the lossy encoded file, and 
receiving step (e) includes automatic activation and use of the lossy encoded file 

' . according to the instructions embodied in the contact closure information. 

36. The improved method of claim 2 wherein transmitting step (e) includes 
transmitting contact closure information in connection with the lossy encoded file, and 
receiving step (g) includes automatic activation and use of the lossy encoded file 
according to the instructions to the tail end user apparatus embodied in the contact closure 

20 information. 

37. The . improved method of claim 3 wherein transmitting step (e) includes 
transmitting contact closure information in connection with the lossy encoded file, and 
receiving_ste P _.(f) includes ..automate activation and use of the lossy encoded file 

25 according to the instructions to the tail end user apparatus embodied in the contact closure 
information. 

38. The improved method of claim 4 wherein transmitting step (f). includes 
transmitting contact closure information in connection with the lossy encoded file, and 

30 receiving step (g) includes automatic activation and use of the lossy encoded file 
according to the instructions to the tail end user apparatus embodied in the contact closure 
information. 

39. The improved method of claim 5 wherein transmitting step (e) includes 
3S transmitting contact closure information in connection with the lossy encoded file, and 
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receiving step (f) includes automatic activation and use of the lossy encoded file 
according to the instructions to the tail end user apparatus embodied in the contact closure 
information. 

5 40. The improved method' of claim 6 wherein transmitting step (d) includes, 
transmitting contact closure information in connection with the lossy encoded file, and 
receiving step (e) includes automatic activation of demand for use of the lossy encoded 
file according to the instructions embodied in the contact closure information. 

to 41. The improved method of claim 7 wherein transmitting step (e) includes 
transmitting contact closure information in connection with the lossy encoded file, and 
receiving step (g) includes automatic activation of demand for use of the lossy encoded 
file according to the instructions to the tail end user apparatus embodied in the contact 
closure information. 

15 

42. The improved method of claim 8 wherein transmitting step (e) includes 
transmitting contact closure information in connection with the lossy encoded file, and 
receiving step (f) includes automatic activation of demand for use of the lossy encoded 
file according to the instructions to the tail end user apparatus embodied in the contact 

20 closure information. 

43. The improved method of claim 9 wherein transmitting step (f) includes 
transmitting contact closure information in connection with .the lossy encoded file, and 
receiving step (g) includes automatic activation of demand for use of the lossy encoded 

23 file according "to the instructions to the tail end user apparatus embodied in the contact - 
closure information. 

44. The improved method of claim 11 wherein transmitting step (d) includes 
transmitting contact closure information in connection with the lossy encoded file; 

■30 receiving step (e) includes automatic activation of demand for use of the lossy encoded 
file according to the instructions embodied in the contact closure information; and 
insertion step (e) includes automatic activation of the insertion according to. the 
instructions embodied in the contact closure information. 
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45. The improved method of claim 12 wherein transmitting step (d) includes 
transmitting contact closure information in connection with the lossy encoded file; 
receiving step (e) includes automatic activation of demand for use of the lossy encoded 
file according to the instructions embodied in the contact closure information; and 
insertion step (e) . includes automatic activation of the insertion according to the 
instructions embodied in the contact closure information. 

46. The improved method of claim 13 wherein transmitting step (e) includes 
transmitting contact closure information in connection with the lossy encoded file, and 
receiving step (f) includes automatic activation of demand for use of the lossy encoded 
file according to the instructions to the tail end user apparatus embodied in the contact 
closure information, 

47. The improved method of claim 15 wherein transmitting step (e) includes 
transmitting contact closure information in connection with the lossy encoded file, and 
receiving step (f) includes automatic activation of demand for use of the lossy encoded 
file according to the instructions to the tail end user apparatus embodied in the contact " 
closure information. 

48. The improved method of claim 16 wherein transmitting step (e) includes 
transmitting contact closure information in connection with the lossy encoded file, and 
receiving step (f) includes automatic activation of demand for use of the lossy encoded 
file according to the instructions to the tail end user apparatus embodied in the contact 
closure information. 

49. The improved method of claim 17 wherein transmitting step (f) includes 
transmitting contact closure information in connection with the lossy encoded file, and 
receiving step (g) includes automatic activation of demand for use of the lossy encoded 
file according to the instructions to the tail end user apparatus embodied in the contact 
closure information. 

50. The improved method of claim 18 wherein transmitting step (e) includes 
transmitting contact closure information in connection with the lossy encoded file, and 
receiving step (f) includes automatic activation of demand for use of the lossy encoded 
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filc according to the instructions to the tail end user apparatus embodied in the contact 
closure information. 

51. The improved method of claim 19 wherein transmitting step (d) includes 
s transmitting contact closure information in connection with the lossy encoded file, and 
receiving step (e) includes automatic activation of demand for use of the lossy encoded 
file according to the instructions to the tail end user apparatus embodied in the contact 
closure information. 

to 52. The improved method of claim 23 wherein transmitting step (f) includes 
transmitting contact closure, information in connection with the lossy encoded file, and 
receiving step (g) includes automatic activation of demand for use of the lossy encoded 
file according to the instructions to the tail end user apparatus . embodied in the contact 
closure information. 

53. The improved method of claim 28 wherein transmitting step (e) includes 
transmitting contact closure information in connection with the lossy encoded file, and. 
receiving step (f) includes automatic activation of demand for use of the lossy encoded 
file according to the instructions to the tail end user apparatus embodied in the contact 
20 closure information. 

,54. The improved method of claim 29 wherein transmitting step (0 includes 
transmitting contact closure information in connection with the lossy encoded file, and 
receiving step (g) includes automatic activation of demand for use of the lossy encoded 
25 ~fUe according' to the instructions "to the tail end user apparatus "embodied- in the contact - 
closure information. 

55. The improved method of claim 33 wherein transmitting step (e) includes 
transmitting contact closure information in connection with the lossy encoded file, and 
30 receiving step (f) includes automatic activation of demand for use of the lossy encoded 
file according to the instructions to the tail end user apparatus embodied in the contact 
closure information. . 
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56. - The improved method of claim 
transmission of the encoded file first to a 
user apparatus served by the hub. 

57. The improved method of claim 
transmission of the encoded file first to a 
user apparatus served by the hub. 



1 wherein the transmission step (d) includes 
central hub and then to the predetermined end 

1 wherein the transmission step (e) includes 
central hub and then to the predetermined end 



58. The improved method of claim 3 wherein the transmission step (e) includes 
transmission of the encoded file first to a central hub and then to the predetermined end 
user apparatus served by the hub. . 

59. The improved method of claim 4 wherein the transmission step (f) includes 
transmission of the encoded file first to a central hub and then to the predetermined end 
user apparatus served by the hub. 

60. The improved method of claim 5 wherein the transmission step (e) includes 
transmission of the encoded file first to a central hub and then to the predetermined end 
user apparatus served by the hub. 

61. The improved method of claim 6 wherein the transmission step (d) includes' 
transmission of the encoded file first to a central hub and then to the predetermined end 
user apparatus served by the hub. 

62. " The improved method of claim 7 wherein the transmission step (e) includes 
transmission of the encoded file first to a central hub and then to the predetermined end 
user apparatus served by the hub. 

63. The improved method of claim 8 wherein the transmission step (e) includes 
transmission of the encoded file first to a central hub and then to the predetermined end 
user apparatus served by the hub. 

64. The improved method of claim 9 wherein the transmission step (f) includes 
transmission of the encoded file first to a central hub and then to the predetermined end 
user apparatus served by the hub. 
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65. The improved method of claim 10 wherein the transmission step (d) includes 
transmission of the encoded file first to a central hub and then to the predetermined end 
user apparatus served by the hub. 

66. . The improved method of claim 1 1 wherein the transmission step (d) includes 
transmission of the encoded file first to a central hub and then to the predetermined end 
user apparatus served by the hub. 

67. The improved method of claim 12 wherein the transmission step (d) includes 
transmission of the encoded file first to a central hub and then to the predetermined end 
user apparatus served by the hub. 

68. The improved method of claim 1 3 wherein the transmission step (d) includes 
transmission of the encoded file first to a central hub and then to the predetermined end 
user apparatus served by the hub. 

69. The improved method of claim 18 wherein the transmission step (e) includes 
transmission of the encoded file first to a central hub and then to the predetermined end 
user apparatus served by the hub. 

70. The improved method of claim 24 wherein the transmission step (d) includes 
transmission of the encoded file first to a central hub and then to the predetermined end 
user apparatus served by the hub, 

71. The improved method of claim 31 wherein the transmission step (f) includes 
transmission of the encoded file first to a central hub and then to the predetermined end 
user apparatus served by the hub. 

72. The improved method , of claim 35 wherein the transmission step (d) includes 
transmission of the encoded file first to a central hub and then to the predetermined end 
user apparatus served by the hub. ' 
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73. The improved method of claim 37 wherein the transmission step (e) includes 
transmission of the encoded file first to a central hub and then to the predetermined end 
user apparatus served by the hub. 

74. The improved method of claim 43. wherein the transmission step (f) includes 
transmission of the encoded file first to a central hub and then to the predetermined end 
user apparatus served by the hub. 

75. The improved method of claim 48 wherein the transmission step (e) includes 
transmission of the encoded file first to a central hub and then to the predetermined end 
user apparatus served by the hub. 

76. The improved method of claim 9 wherein: step (a) includes receiving a second 
audio signal on the production system; step (c) includes digitally encoding the second 
audio signal with the lossy compression algorithm to yield a second lossy encoded file of 
lossy audio information; step (c) includes incorporating a play list into the data file; step 
(f) includes transmitting the first and second lossy encoded files along with the data file; 
and step (g) includes receiving and storing the first and second lossy encoded files on the 
predetermined tail end apparatus and use of the encoded files according to the instructions 
in the play list. 

DATED this Third Day of August, 2000 
Starguide Digital Networks, Inc. 
Patent Attorneys for the Applicant 
SPRUSON & FERGUSON 
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200 




202 re 9' ster audio segment, audio server passes 

information (file name, start offset and end offset) as 
segment request 



204 Store segment request on audio segment table and 
assign and return a unique segment handle 



206 



208 



Audio server passes segment handle and control 
information to driver as a load segment information 
request 




210 



212 



Access audio file based on segment handle and store 
" " requested and data frames in buffer 



Issues a data IOC I L request to DAC and wait for next 
data request from driver 



<^~^ To Fig. 10B 

Fig. 1 0A 

" SUBSTITUTE SHEET (RULE 26) 
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214 DAC loads data Barnes into input buffer of 

designated decoder and waits for a start message 



216 

Audio server sends a decoder play request to DAC 

t ~~ 

218 Decod er plays audio and when decoder input buffer 
is partially complete it issues a request audio data 
message 



T 



220 Return next set of data frames to DAC and load new 
set of data frames and waits for next data request 
from driver 



222 Repeat steps 21 8 to 220 until no more data in audio 

file 



226 DAC issue and end of segment event when last 
, frame js. played, , 



228 



Remove segment from buffer and close file and 
perform additional processing if any 

. t . 



Fig. 10B 
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